search

aerogear / proposals

AeroGear Proposals
Apache License 2.0
0 stars 17 forks source link

✨ UPS Integration with OpenShift Proposal #31

Closed david-martin closed 6 years ago

matzew commented 6 years ago

so far, so good

matzew commented 6 years ago

One question, @david-martin: We can not use Keycloak's "Identity Provider" feature (for Openshift), due to missing roles and permission mappings?

david-martin commented 6 years ago

One question, @david-martin: We can not use Keycloak's "Identity Provider" feature (for Openshift), due to missing roles and permission mappings?

@matzew I wouldn't say 'can not', but it would be tricky to do it, plus the experience might be odd. You'd be logging into UPS via Keycloak via OpenShift. I'm not sure how that would look from the user's point of view. Plus we'd need to figure out how OpenShift User roles get mapped to Keycloak roles, and where those mapping happens.

wtrocki commented 6 years ago

@david-martin Quick question. Is this something that we should consider for current push SDKs or this will be done in the future?

david-martin commented 6 years ago

@david-martin Quick question. Is this something that we should consider for current push SDKs or this will be done in the future?

It will need to be considered as part for delivering UPS on OpenShift, where the Aerogear SDK includes UPS support. So it's very relevant to any work with moving the ups sdks into the main sdk repos

david-martin commented 6 years ago

@wtrocki @danielpassos Some really good points in the comments above. After chatting with passos offline, I have more understanding of where you both are coming from with the above feedback.

So, there is no value in creating a variant without having the associated credentials also (e.g. p12, master secret). Therefore, I am questioning the value of automatically syncing mobile clients to variants as soon as a mobile client is created. However, is there value in syncing after they developer has created variant?

For example:

If the developer comes back later to setup the ios variant for their Cordova app, they can go through a similar process:

Thoughts?

matzew commented 6 years ago

So, there is no value in creating a variant without having the associated credentials also (e.g. p12, master secret). ... Therefore, I am questioning the value of automatically syncing mobile clients to variants as soon as a mobile client is created.

I think this variant creation should be done only, when push service is weird/bind/conntected to that MAR (Mobile Application Representation). Cordova/Xamarin are different here, as their "unified code" runs on different platforms, so needs very likely APNS and FCM for push - while pure iOS/Android are logically tied to just one variant

matzew commented 6 years ago

However, is there value in syncing after they developer has created variant?

yes - after the MAR has some relationship on push, the sync is pretty useful, and needed - I like the flow you outlined here

david-martin commented 6 years ago

@danielpassos @wtrocki @matzew After more feedback and some discussions with @wtrocki, here's some more refined thoughts.

So, I'm still suggesting everything from my previous comment https://github.com/aerogear/proposals/pull/31#issuecomment-372456779 with some modifictions/additions:

I think allowing the developer to manually control the link between clients and variants is important for flexibility during development. We need this link(s) in order to tie back any push activity to a Mobile Client in OpenShift.

One potential point of contention with using mobile-services.json for iOS is that it's different than what the developer might expect i.e. a plist file

EDIT: @wtrocki @danielpassos @matzew I've pushed a rewrite for the OpenShift Integration section. It's mostly what I'm saying above, but it does include example mobile-services.json files