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

[Lukas Fryc]

@Andres: I believe Bruno's email means we will no longer have bundled
Keycloak. I had your screens on mind.. we would need certainly to change
them a bit, but I believe UI-based first-time configuration would be much
simpler for users then a CLI-based one.

On Mon, Jan 11, 2016 at 2:21 PM, Andres Galante <agalante at redhat.com> wrote:

> On the first screens I designed for UPS there there was a first step
> before login to decide weather to use keycloak or not:
>
> https://rawgit.com/andresgalante/UPS/master/keycloack-setup.html
> https://rawgit.com/andresgalante/UPS/master/login.html
>
>
>
> On Mon, Jan 11, 2016 at 9:50 AM, Lukas Fryc <lfryc at redhat.com> wrote:
>
>> Hi Bruno,
>>
>> are there any plans or thoughts to allow association of the UPS with
>> Keycloak instance via web UI?
>>
>> 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. 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
>>>    )
>>>
>>> 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
>>>
>>>    - 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
>>> ​
>>> --
>>> - abstractj
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Lukáš Fryč
Software Engineer
Red Hat Mobile | AeroGear.org, FeedHenry.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20160111/f99f4a81/attachment-0001.html