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

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