Re: [aerogear-dev] AGPUSH-1047: UPS decoupling from Keycloak

Sorry for the late answer Matthias. On Wed, Jan 13, 2016 at 12:06 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Oh, I think, another problem with the decoupling is, that today we have a > bunch of files that know about the URL of the KC server: > > * > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/admin... > > > Ok, we could install that w/ bower/npm ? > That's my thought. > > But, these are also there, and do require the URL: > * > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/serve... > * > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/serve... > * > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/serve... > * > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/serve... > > Ideally this knowledge would not be required / hard-coded > That's the plan. Dynamic client registration won't fix all the problems. So pretty much the ideas are: - For admin-ui: serve the dynamic information using a Restful endpoint. Like Lukas already suggested some time ago

- For the JEE application: provide it dynamically using KeycloakConfigResolver ( https://github.com/keycloak/keycloak/blob/master/examples/multi-tenant/sr... )

As soon as I get such implementations working, I will let everyone know.

> > -Matthias > > On Mon, Jan 11, 2016 at 8:18 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > wrote: > >> Thanks Matthias, will take into consideration all of the comments >> bellow. >> >> On Mon, Jan 11, 2016 at 1:43 PM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >>> >>> >>> On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; >>> wrote: >>> >>>> Good morning, today I have a conversation with Matthias about the >>>> decoupling for UPS from Keycloak[1]. Also, during the week, I have a >>>> brainstorm on some ideas with Stian, to figure out the better way to >>>> achieve this. >>>> Motivation >>>> >>>> The reason why we want to decouple UPS from Keycloak, is due to the >>>> fact that today is not possible to have UPS and Keycloak in a separated >>>> infrastructure. Currently we bundle it. Keycloak is still and will always >>>> be our default security solution. >>>> >>>> There’s no intentions or future plans to make use of another security >>>> provider. >>>> Actions items >>>> >>>> During these conversations I identified some action items for myself >>>> which I would like to share. Also, I’m going to start to file Jiras under >>>> AGPUSH-1047 umbrella. >>>> 1. Create a client cli script using Aesh to link UPS with Keycloak >>>> >>>> The script would ask for admin’s username/password or an initial >>>> registration token. >>>> >>> I think for us it would be best if the script requires the >>> username:password of the admin, this helps for a full automation (e.g. via >>> Ansible/Chef) >>> >>> If a initial token is needed, that would mean an extra step to actually >>> get it (e.g. via an API call). So, I'd be happy to start w/ the admin >>> username:password >>> >>> >>> >>>> After that, the script would make use of the dynamic client >>>> registration service to create the required clients with Keycloak. >>>> 2. Themes >>>> >>>> For theme definition we have 2 scenarios: >>>> >>>> - >>>> >>>> Already existent server in use >>>> >>>> Nothing will be changed. It’s already an agreement that the >>>> current theme should be neutral and not changed. >>>> - >>>> >>>> Brand new instance of Keycloak with UPS theme >>>> >>>> For scenarios where people want custom theme from UPS, people can >>>> just deploy it, exactly like described here ( >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html... >>>> ) >>>> >>>> >>> IMO this is more on the nice to have side of the house :-) >>> >>> >>>> >>>> - >>>> >>>> 3. Creation of roles for clients >>>> >>>> For the very first draft I’m planning to just import ups-realm.json >>>> (manual process) and see how it goes. >>>> >>>> The ideal is to extend the client registration service on Keycloak to >>>> allow creating roles for a client. For now, let’s just start simple — this >>>> can be tricky and require more discussion/time. >>>> >>> >>> It would be good if the above Aesh script, would be able to have the >>> realm.json file as one of its arguments, so there would be no need for a >>> manual import, via the UI. >>> This would be generally useful, so we can have in automated testing a >>> different realm.json file e.g. to have client applications for automated >>> http request against the endpoints. Today, this needs to be done manually: >>> >>> https://github.com/aerogear/aerogear-unifiedpush-server/tree/master/node.js >>> >>> >>> >>>> 4. Creating of roles for users >>>> >>>> Same as item 3, for now assume that user exist with “admin” role. The >>>> ideal is the creation of a super user to access UPS. For now, users >>>> can manually register/import users that can access UPS through the KC admin >>>> console. >>>> >>> >>> As on 3) if the script takes in the JSON file for the actual realm, we >>> are good to go here, as one can define all the roles in there. >>> >>> >>>> 5. UPS realm >>>> >>>> Discussing with Matthias we came up with 2 scenarios: >>>> >>>> - Make use of an already existent realm in use >>>> >>>> In this scenarios, people want to make use of UPS, but don’t want to >>>> have a new realm dedicated for it. We’re going to make use of the dynamic >>>> client registration against the realm specified. >>>> >>>> - Brand new instance of Keycloak with UPS theme >>>> >>>> For people willing to have a separated realm not mixed up with master. >>>> In this scenario we provide ups-realm.json as part of documentation >>>> or demo purposes and make use of the dynamic client registration process. >>>> >>> >>> I think the separated realm is a must - also this is a true isolation. >>> E.g. I would not ultimately want to expose my "ups test clients" on the >>> global master realm, similar w/ users/roles. >>> >>> >>>> Note: We probably can benefit of item 1 to import the json file if >>>> necessary. >>>> 6. Multiple UPS instances with a single instance of KC >>>> >>>> It would require to extend the client registration service and some >>>> work on KC. Depending on the time, it can be done. But for now we’re going >>>> to assume that the relationship will be 1:1, into other words, one instance >>>> of UPS and one instance of KC. >>>> >>> That's fine to assume 1:1 mapping. But I agree that, eventually, this >>> is something interesting for Keycloak, not related to the UPS >>> >>> >>> >>>> For corp scenarios we would end up with: >>>> Test >>>> >>>> - testing.ups.mybank.com >>>> - testing.keycloak.mybank.com >>>> >>>> Production >>>> >>>> - ups.mybank.com >>>> - keycloak.mybank.com >>>> >>>> If you have any questions or feedback, I’m listening. >>>> >>>> https://issues.jboss.org/browse/AGPUSH-1047 >>>> >>> >>> This is good content, and I like the direction it is going :-) Besides >>> my few comments >>> >>> >>> >>>> ​ >>>> -- >>>> - abstractj >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> - abstractj >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- - abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev