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

I think those screens will help in the future when we decided to move have the command line and Web UI as alternatives. Feel free to attach at the Jira umbrella to be revisited. On Mon, Jan 11, 2016 at 1:01 PM, Lukas Fryc <lfryc(a)redhat.com&gt; wrote: > @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(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)abstractj.org&gt; >>> 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... >>>> ) >>>> >>>> 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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- - abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev