Thanks Matthias, will take into consideration all of the comments bellow.On Mon, Jan 11, 2016 at 1:43 PM, Matthias Wessendorf <matzew@apache.org> wrote:On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <bruno@abstractj.org> 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:passwordAfter 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#d4e2340)
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: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
realmnot mixed up withmaster. In this scenario we provideups-realm.jsonas 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
jsonfile 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 UPSFor corp scenarios we would end up with:
Test
Production
If you have any questions or feedback, I’m listening.
This is good content, and I like the direction it is going :-) Besides my few comments--
- abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev--- abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev