On Mon, Jan 11, 2016 at 4:45 PM, Matthias Wessendorf <matzew@apache.org> wrote:


On Mon, Jan 11, 2016 at 1:50 PM, Lukas Fryc <lfryc@redhat.com> wrote:
Hi Bruno, 

are there any plans or thoughts to allow association of the UPS with Keycloak instance via web UI?

Not now - I do honestly think a pure CLI / script based setup is much simpler to implement and flexible (think automation). Perhaps, in a later version, we can offer UI, but I think for 1.2.0 we don't need that
+1
Beside that I like your action plan Bruno, please let us know if we can help on any of these items.  

-Matthias
 

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. 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:

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.

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.

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.

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.

For corp scenarios we would end up with:

Test

Production

If you have any questions or feedback, I’m listening.

https://issues.jboss.org/browse/AGPUSH-1047

​
--
- abstractj

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Lukáš Fryč
Software Engineer
Red Hat Mobile | AeroGear.org, FeedHenry.org

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev