aerogear-dev

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

classic Classic list List threaded Threaded
♦
♦
 14 messages Options
Bruno Oliveira
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Bruno Oliveira

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.

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Lukas Fryc-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Lukas Fryc-2
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Andres Galante
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Andres Galante
On the first screens I designed for UPS there there was a first step before login to decide weather to use keycloak or not:




On Mon, Jan 11, 2016 at 9:50 AM, Lukas Fryc <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Lukas Fryc-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Lukas Fryc-2
@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 <[hidden email]> 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:




On Mon, Jan 11, 2016 at 9:50 AM, Lukas Fryc <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Matthias Wessendorf
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Matthias Wessendorf
In reply to this post by Bruno Oliveira


On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <[hidden email]> 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:


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:

 

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

Production

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
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Matthias Wessendorf
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Matthias Wessendorf
In reply to this post by Lukas Fryc-2


On Mon, Jan 11, 2016 at 1:50 PM, Lukas Fryc <[hidden email]> 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

-Matthias
 

On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Sebastien Blanc
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Sebastien Blanc


On Mon, Jan 11, 2016 at 4:45 PM, Matthias Wessendorf <[hidden email]> wrote:


On Mon, Jan 11, 2016 at 1:50 PM, Lukas Fryc <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Bruno Oliveira
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Bruno Oliveira
In reply to this post by Lukas Fryc-2


On Mon, Jan 11, 2016 at 10:50 AM, Lukas Fryc <[hidden email]> wrote:
Hi Bruno, 

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

No plans for web UI at the moment. I'd like to start very simple and later we can think about it.

 

On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
- abstractj

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Bruno Oliveira
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Bruno Oliveira
In reply to this post by Lukas Fryc-2
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 <[hidden email]> 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 <[hidden email]> 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:




On Mon, Jan 11, 2016 at 9:50 AM, Lukas Fryc <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
- abstractj

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Bruno Oliveira
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Bruno Oliveira
In reply to this post by Matthias Wessendorf
Thanks Matthias, will take into consideration all of the comments bellow. 

On Mon, Jan 11, 2016 at 1:43 PM, Matthias Wessendorf <[hidden email]> wrote:


On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <[hidden email]> 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:


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:

 

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

Production

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
- abstractj

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Lukas Fryc-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Lukas Fryc-2
In reply to this post by Bruno Oliveira
The jira for a Getting Started via UI was actually there already: https://issues.jboss.org/browse/AGPUSH-1110 :-)

On Mon, Jan 11, 2016 at 8:17 PM, Bruno Oliveira <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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:




On Mon, Jan 11, 2016 at 9:50 AM, Lukas Fryc <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
- abstractj

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



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

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Matthias Wessendorf
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Matthias Wessendorf
In reply to this post by Bruno Oliveira
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:


Ok, we could install that w/ bower/npm ?

But, these are also there, and do require the URL:

Ideally this knowledge would not be required / hard-coded

-Matthias

On Mon, Jan 11, 2016 at 8:18 PM, Bruno Oliveira <[hidden email]> wrote:
Thanks Matthias, will take into consideration all of the comments bellow. 

On Mon, Jan 11, 2016 at 1:43 PM, Matthias Wessendorf <[hidden email]> wrote:


On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <[hidden email]> 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:


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:

 

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

Production

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
- abstractj

_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Bruno Oliveira
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Bruno Oliveira
Sorry for the late answer Matthias.

On Wed, Jan 13, 2016 at 12:06 PM, Matthias Wessendorf <[hidden email]> 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:


Ok, we could install that w/ bower/npm ?

That's my thought.
 

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

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 <[hidden email]> wrote:
Thanks Matthias, will take into consideration all of the comments bellow. 

On Mon, Jan 11, 2016 at 1:43 PM, Matthias Wessendorf <[hidden email]> wrote:


On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <[hidden email]> 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:


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:

 

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

Production

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
- abstractj

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
- abstractj

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Matthias Wessendorf
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Matthias Wessendorf


On Mon, Jan 18, 2016 at 5:28 PM, Bruno Oliveira <[hidden email]> wrote:
Sorry for the late answer Matthias.

On Wed, Jan 13, 2016 at 12:06 PM, Matthias Wessendorf <[hidden email]> 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:


Ok, we could install that w/ bower/npm ?

That's my thought.
 

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
 

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 <[hidden email]> wrote:
Thanks Matthias, will take into consideration all of the comments bellow. 

On Mon, Jan 11, 2016 at 1:43 PM, Matthias Wessendorf <[hidden email]> wrote:


On Fri, Jan 8, 2016 at 2:53 PM, Bruno Oliveira <[hidden email]> 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:


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:

 

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

Production

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
- abstractj

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
- abstractj

_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Free forum by Nabble Edit this page