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

Tue Jan 19 02:48:43 EST 2016

On Mon, Jan 18, 2016 at 5:28 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

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

Ok, makes sense to automatically receive that info from the UPS server to
the UI, using a HTTP API

> - 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
> )
>

Not sure I fully understand how this helps to receive realm info from a
different server, but I guess a working example/prototype of what we want
will show better than word :)

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

awesome!

>
>
>
>>
>> -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
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160119/aec41945/attachment-0001.html 