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

Mon Jan 18 11:28:52 EST 2016

Sorry for the late answer Matthias.

On Wed, Jan 13, 2016 at 12:06 PM, Matthias Wessendorf <matzew at apache.org>
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-ui/app/index.html#L159
>
>
> 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/servers/ups-wildfly/src/main/webapp/config/admin-ui-keycloak.json#L3
> *
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-wildfly/src/main/webapp/WEB-INF/keycloak.json#L3
> *
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-as7/src/main/webapp/config/admin-ui-keycloak.json#L3
> *
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-as7/src/main/webapp/WEB-INF/keycloak.json#L3
>
> 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/src/main/java/org/keycloak/example/multitenant/control/PathBasedKeycloakConfigResolver.java
)

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 at abstractj.org>
> wrote:
>
>> Thanks Matthias, will take into consideration all of the comments bellow.
>>
>> On Mon, Jan 11, 2016 at 1:43 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <bruno at 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: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#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:
>>>
>>> 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> - abstractj
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
- abstractj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160118/5ded27e7/attachment-0001.html 