Hi, Would like to start a discussion about how to enable KC as an Authentication Broker in order to supported Chained Federation and also Identity Federation. First of all, some background about what this is all about. Currently KeyCloak provides two basic types of authentication (correct me if I'm wrong, please): 1) Local authentication (based on some credential type enabled to a realm) 2) Social authentication Local authentication is about authenticating the user locally using KC's own identity store. Nothing special here. And Social Authentication which allows users to choose the Social IdP they want to authenticate with. In this case, the IdP is always one of the built-in social providers supported by KC such as Facebook, Google, Twitter, Github and so forth. When doing social, the user is automatically provisioned in KC identity store after a successful authentication. The user does not need to fill a registration form and can access the application very quickly. During the provisioning some basic information is retrieved from the social provider such as email, firstname and so forth. These are very basic information, any other information such as those related with authorization policies - eg.: roles and groups - must be defined later via KC's admin console. Another important characteristic of social authentication is that the application receives a KC token and not the token that was issued by the social IdP during the authentication process. If the application wants to consume resources from the resource provider he was authenticated it must obtain the access token(again) by itself prior to invoke the resource provider API. Assuming all those social providers are based on oAuth 1.0 or 2.0. That said, the Authentication Broker functionality aims to cover the same use cases but with a lot of more flexibility on how you setup identity providers(not only social ones) and the different federation protocols they may support such as SAML, OpenID, oAuth and so forth. This is useful when an enterprise is providing services to different customers(IdP) and does not want to manage many to many relationships. When using a broker, the authentication steps are pretty much the same when you are using social authentication, with important differences on how you support different identity providers, different federation protocols, how users are provisioned and how claims and attributes are resolved. The brokering functionality can be done in two ways depending if the broker service is acting as a gateway or not. When acting as a gateway, the broker will respond to the application the same token issued by the trusted identity provider. For instance, if the user selects a SAML IdP to authenticate with, the application will receive a SAML Response. In this case, the application must also be prepared to handle a specific federation protocol. However, the broker service can also be used to completely abstract from the application the protocol used to authenticate an user. In this case, the application will just receive an ordinary KC token after a successful authentication. In both cases, the broker acts as an intermediary where specific security policies can be applied when users try to authenticate themselves against a 3rd party IdP. That brings a lot of value when you think about auditing, authorization and how users are provisioned when federation of identities is needed. This also allows existing security infrastructures (eg.: SAML-based infrastructures) to benefit from KC's support for cloud, rest and mobile use cases. I think this is enough to start a discussion. I've an initial discussion with Stian about all that and we agreed that abstract the protocol from applications should be prioritized. The main reason is that it makes life easier for applications so they only need to know about KC tokens and nothing else. However that brings some new requirements around user provisioning and claim/attribute resolution or mapping. But that would be another thread.

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 19 November, 2014 8:27:58 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Wednesday, November 19, 2014 4:39:52 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > > Hi, > > > > Would like to start a discussion about how to enable KC as an > > Authentication Broker in order to supported Chained Federation and > > also Identity Federation. First of all, some background about what > > this is all about. > > > > Currently KeyCloak provides two basic types of authentication > > (correct > > me if I'm wrong, please): > > > > 1) Local authentication (based on some credential type enabled > > to > > a realm) > > 2) Social authentication > > > > Local authentication is about authenticating the user locally using > > KC's own identity store. Nothing special here. And Social > > Authentication which allows users to choose the Social IdP they want > > to authenticate with. In this case, the IdP is always one of the > > built-in social providers supported by KC such as Facebook, Google, > > Twitter, Github and so forth. > > > > When doing social, the user is automatically provisioned in KC > > identity store after a successful authentication. The user does not > > need to fill a registration form and can access the application very > > quickly. During the provisioning some basic information is retrieved > > from the social provider such as email, firstname and so forth. > > These > > are very basic information, any other information such as those > > related with authorization policies - eg.: roles and groups - must > > be > > defined later via KC's admin console. > > > > Another important characteristic of social authentication is that > > the > > application receives a KC token and not the token that was issued by > > the social IdP during the authentication process. If the application > > wants to consume resources from the resource provider he was > > authenticated it must obtain the access token(again) by itself prior > > to invoke the resource provider API. Assuming all those social > > providers are based on oAuth 1.0 or 2.0. > > > > That said, the Authentication Broker functionality aims to cover the > > same use cases but with a lot of more flexibility on how you setup > > identity providers(not only social ones) and the different > > federation > > protocols they may support such as SAML, OpenID, oAuth and so forth. > > This is useful when an enterprise is providing services to different > > customers(IdP) and does not want to manage many to many > > relationships. When using a broker, the authentication steps are > > pretty much the same when you are using social authentication, with > > important differences on how you support different identity > > providers, different federation protocols, how users are provisioned > > and how claims and attributes are resolved. > > > > The brokering functionality can be done in two ways depending if the > > broker service is acting as a gateway or not. When acting as a > > gateway, the broker will respond to the application the same token > > issued by the trusted identity provider. For instance, if the user > > selects a SAML IdP to authenticate with, the application will > > receive > > a SAML Response. In this case, the application must also be prepared > > to handle a specific federation protocol. > > > > However, the broker service can also be used to completely abstract > > from the application the protocol used to authenticate an user. In > > this case, the application will just receive an ordinary KC token > > after a successful authentication. > > > > In both cases, the broker acts as an intermediary where specific > > security policies can be applied when users try to authenticate > > themselves against a 3rd party IdP. That brings a lot of value when > > you think about auditing, authorization and how users are > > provisioned > > when federation of identities is needed. This also allows existing > > security infrastructures (eg.: SAML-based infrastructures) to > > benefit > > from KC's support for cloud, rest and mobile use cases. > > > > I think this is enough to start a discussion. I've an initial > > discussion with Stian about all that and we agreed that abstract the > > protocol from applications should be prioritized. The main reason is > > that it makes life easier for applications so they only need to know > > about KC tokens and nothing else. However that brings some new > > requirements around user provisioning and claim/attribute resolution > > or mapping. But that would be another thread. > > > > Can you elaborate on "abstract the protocol from applications"? Not > sure what you mean by that. IDP federation should be configured at the > realm level and really has nothing to do with applications. > > I'm really happy that somebody is doing this. We're getting a real > impressive feature set! Sure. What I meant was that the application only knows about KC tokens nothing else. It will always receive a KC token regardless the protocol used to authenticate the user against a 3rd party IdP (saml, oidc, whatever). The example I gave was about an user trying to authenticate against a SAML IdP. In this case, after a successful authentication on the IdP, the IdP will issue a token to KC. Then KC will validate the token, perform trust and security checks, do user provisioning and attribute/claim resolution to finally issue a KC token and redirect the user to the application. If the app is configured to use openid in KC then it will receive a openid token from KC, not saml ... The other scenario is pretty much the same. The difference is that KC will not issue its own token but just replay the token issued by the 3rd party IdP to the service provider. I agree that this config goes at the realm level. For instance, to create and enable providers for being used. However, I think we would need some specific configuration for applications as well. Specially when defining default roles, mapping attributes. Another example of application config is when using a OIDC/oAuth IdP. You may want to define scopes per-application. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

1) Sounds like something definitely worth aiming for. On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > I just wanted to quickly list the additional work we discussed so everyone can think about it (in no particular order): > > 1) Mapping of tokens - how do we deal with mapping of an external token to a KC token? For example an external token with attribute 'group' that contains 'sales' and 'manager' could be mapped to 'manager' role for 'sales app in a KC token. Could we use Drools? This could also be used in user federation to allow more complex mapping of roles/groups than a simple 1-1 > 2) Retrieving tokens - if an application wants to retrieve the external token (for example to view Facebook friends if user logged in with Facebook) > 3) Configure scope - currently for social we only request a very limited scope (basic profile and email), to for example view Facebook friends we'd need to ask for that as well > 4) Selecting provider - currently in social (and for first pass of brokering) we have an icon user has to select, but can we select the provider in a different way (for example ask user for email, and select based on email domain) > 5) Gateway - don't create a KC token, but just forward the external token > > IMO 1) is a killer feature, as it would allow companies to add external users without having to modify their applications. Issue with 5) is that applications need to understand more than one token, which would require rewriting applications. > > This work is also somewhat related to other authentication mechanisms (for example Kerberos ticket, LDAP and passwordless). > > ----- Original Message ----- >> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> To: "Bill Burke" <bburke(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Wednesday, 19 November, 2014 8:27:58 PM >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Wednesday, November 19, 2014 4:39:52 PM >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>> >>> >>> >>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: >>>> Hi, >>>> >>>> Would like to start a discussion about how to enable KC as an >>>> Authentication Broker in order to supported Chained Federation and >>>> also Identity Federation. First of all, some background about what >>>> this is all about. >>>> >>>> Currently KeyCloak provides two basic types of authentication >>>> (correct >>>> me if I'm wrong, please): >>>> >>>> 1) Local authentication (based on some credential type enabled >>>> to >>>> a realm) >>>> 2) Social authentication >>>> >>>> Local authentication is about authenticating the user locally using >>>> KC's own identity store. Nothing special here. And Social >>>> Authentication which allows users to choose the Social IdP they want >>>> to authenticate with. In this case, the IdP is always one of the >>>> built-in social providers supported by KC such as Facebook, Google, >>>> Twitter, Github and so forth. >>>> >>>> When doing social, the user is automatically provisioned in KC >>>> identity store after a successful authentication. The user does not >>>> need to fill a registration form and can access the application very >>>> quickly. During the provisioning some basic information is retrieved >>>> from the social provider such as email, firstname and so forth. >>>> These >>>> are very basic information, any other information such as those >>>> related with authorization policies - eg.: roles and groups - must >>>> be >>>> defined later via KC's admin console. >>>> >>>> Another important characteristic of social authentication is that >>>> the >>>> application receives a KC token and not the token that was issued by >>>> the social IdP during the authentication process. If the application >>>> wants to consume resources from the resource provider he was >>>> authenticated it must obtain the access token(again) by itself prior >>>> to invoke the resource provider API. Assuming all those social >>>> providers are based on oAuth 1.0 or 2.0. >>>> >>>> That said, the Authentication Broker functionality aims to cover the >>>> same use cases but with a lot of more flexibility on how you setup >>>> identity providers(not only social ones) and the different >>>> federation >>>> protocols they may support such as SAML, OpenID, oAuth and so forth. >>>> This is useful when an enterprise is providing services to different >>>> customers(IdP) and does not want to manage many to many >>>> relationships. When using a broker, the authentication steps are >>>> pretty much the same when you are using social authentication, with >>>> important differences on how you support different identity >>>> providers, different federation protocols, how users are provisioned >>>> and how claims and attributes are resolved. >>>> >>>> The brokering functionality can be done in two ways depending if the >>>> broker service is acting as a gateway or not. When acting as a >>>> gateway, the broker will respond to the application the same token >>>> issued by the trusted identity provider. For instance, if the user >>>> selects a SAML IdP to authenticate with, the application will >>>> receive >>>> a SAML Response. In this case, the application must also be prepared >>>> to handle a specific federation protocol. >>>> >>>> However, the broker service can also be used to completely abstract >>>> from the application the protocol used to authenticate an user. In >>>> this case, the application will just receive an ordinary KC token >>>> after a successful authentication. >>>> >>>> In both cases, the broker acts as an intermediary where specific >>>> security policies can be applied when users try to authenticate >>>> themselves against a 3rd party IdP. That brings a lot of value when >>>> you think about auditing, authorization and how users are >>>> provisioned >>>> when federation of identities is needed. This also allows existing >>>> security infrastructures (eg.: SAML-based infrastructures) to >>>> benefit >>>> from KC's support for cloud, rest and mobile use cases. >>>> >>>> I think this is enough to start a discussion. I've an initial >>>> discussion with Stian about all that and we agreed that abstract the >>>> protocol from applications should be prioritized. The main reason is >>>> that it makes life easier for applications so they only need to know >>>> about KC tokens and nothing else. However that brings some new >>>> requirements around user provisioning and claim/attribute resolution >>>> or mapping. But that would be another thread. >>>> >>> >>> Can you elaborate on "abstract the protocol from applications"? Not >>> sure what you mean by that. IDP federation should be configured at the >>> realm level and really has nothing to do with applications. >>> >>> I'm really happy that somebody is doing this. We're getting a real >>> impressive feature set! >> >> Sure. What I meant was that the application only knows about KC tokens >> nothing else. It will always receive a KC token regardless the protocol used >> to authenticate the user against a 3rd party IdP (saml, oidc, whatever). The >> example I gave was about an user trying to authenticate against a SAML IdP. >> In this case, after a successful authentication on the IdP, the IdP will >> issue a token to KC. Then KC will validate the token, perform trust and >> security checks, do user provisioning and attribute/claim resolution to >> finally issue a KC token and redirect the user to the application. If the >> app is configured to use openid in KC then it will receive a openid token >> from KC, not saml ... >> >> The other scenario is pretty much the same. The difference is that KC will >> not issue its own token but just replay the token issued by the 3rd party >> IdP to the service provider. >> >> I agree that this config goes at the realm level. For instance, to create and >> enable providers for being used. However, I think we would need some >> specific configuration for applications as well. Specially when defining >> default roles, mapping attributes. Another example of application config is >> when using a OIDC/oAuth IdP. You may want to define scopes per-application. >> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

1) Sounds like something definitely worth aiming for. On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > I just wanted to quickly list the additional work we discussed so everyone can think about it (in no particular order): > > 1) Mapping of tokens - how do we deal with mapping of an external token to a KC token? For example an external token with attribute 'group' that contains 'sales' and 'manager' could be mapped to 'manager' role for 'sales app in a KC token. Could we use Drools? This could also be used in user federation to allow more complex mapping of roles/groups than a simple 1-1 > 2) Retrieving tokens - if an application wants to retrieve the external token (for example to view Facebook friends if user logged in with Facebook) > 3) Configure scope - currently for social we only request a very limited scope (basic profile and email), to for example view Facebook friends we'd need to ask for that as well > 4) Selecting provider - currently in social (and for first pass of brokering) we have an icon user has to select, but can we select the provider in a different way (for example ask user for email, and select based on email domain) > 5) Gateway - don't create a KC token, but just forward the external token > > IMO 1) is a killer feature, as it would allow companies to add external users without having to modify their applications. Issue with 5) is that applications need to understand more than one token, which would require rewriting applications. > > This work is also somewhat related to other authentication mechanisms (for example Kerberos ticket, LDAP and passwordless). > > ----- Original Message ----- >> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> To: "Bill Burke" <bburke(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Wednesday, 19 November, 2014 8:27:58 PM >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Wednesday, November 19, 2014 4:39:52 PM >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>> >>> >>> >>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: >>>> Hi, >>>> >>>> Would like to start a discussion about how to enable KC as an >>>> Authentication Broker in order to supported Chained Federation and >>>> also Identity Federation. First of all, some background about what >>>> this is all about. >>>> >>>> Currently KeyCloak provides two basic types of authentication >>>> (correct >>>> me if I'm wrong, please): >>>> >>>> 1) Local authentication (based on some credential type enabled >>>> to >>>> a realm) >>>> 2) Social authentication >>>> >>>> Local authentication is about authenticating the user locally using >>>> KC's own identity store. Nothing special here. And Social >>>> Authentication which allows users to choose the Social IdP they want >>>> to authenticate with. In this case, the IdP is always one of the >>>> built-in social providers supported by KC such as Facebook, Google, >>>> Twitter, Github and so forth. >>>> >>>> When doing social, the user is automatically provisioned in KC >>>> identity store after a successful authentication. The user does not >>>> need to fill a registration form and can access the application very >>>> quickly. During the provisioning some basic information is retrieved >>>> from the social provider such as email, firstname and so forth. >>>> These >>>> are very basic information, any other information such as those >>>> related with authorization policies - eg.: roles and groups - must >>>> be >>>> defined later via KC's admin console. >>>> >>>> Another important characteristic of social authentication is that >>>> the >>>> application receives a KC token and not the token that was issued by >>>> the social IdP during the authentication process. If the application >>>> wants to consume resources from the resource provider he was >>>> authenticated it must obtain the access token(again) by itself prior >>>> to invoke the resource provider API. Assuming all those social >>>> providers are based on oAuth 1.0 or 2.0. >>>> >>>> That said, the Authentication Broker functionality aims to cover the >>>> same use cases but with a lot of more flexibility on how you setup >>>> identity providers(not only social ones) and the different >>>> federation >>>> protocols they may support such as SAML, OpenID, oAuth and so forth. >>>> This is useful when an enterprise is providing services to different >>>> customers(IdP) and does not want to manage many to many >>>> relationships. When using a broker, the authentication steps are >>>> pretty much the same when you are using social authentication, with >>>> important differences on how you support different identity >>>> providers, different federation protocols, how users are provisioned >>>> and how claims and attributes are resolved. >>>> >>>> The brokering functionality can be done in two ways depending if the >>>> broker service is acting as a gateway or not. When acting as a >>>> gateway, the broker will respond to the application the same token >>>> issued by the trusted identity provider. For instance, if the user >>>> selects a SAML IdP to authenticate with, the application will >>>> receive >>>> a SAML Response. In this case, the application must also be prepared >>>> to handle a specific federation protocol. >>>> >>>> However, the broker service can also be used to completely abstract >>>> from the application the protocol used to authenticate an user. In >>>> this case, the application will just receive an ordinary KC token >>>> after a successful authentication. >>>> >>>> In both cases, the broker acts as an intermediary where specific >>>> security policies can be applied when users try to authenticate >>>> themselves against a 3rd party IdP. That brings a lot of value when >>>> you think about auditing, authorization and how users are >>>> provisioned >>>> when federation of identities is needed. This also allows existing >>>> security infrastructures (eg.: SAML-based infrastructures) to >>>> benefit >>>> from KC's support for cloud, rest and mobile use cases. >>>> >>>> I think this is enough to start a discussion. I've an initial >>>> discussion with Stian about all that and we agreed that abstract the >>>> protocol from applications should be prioritized. The main reason is >>>> that it makes life easier for applications so they only need to know >>>> about KC tokens and nothing else. However that brings some new >>>> requirements around user provisioning and claim/attribute resolution >>>> or mapping. But that would be another thread. >>>> >>> >>> Can you elaborate on "abstract the protocol from applications"? Not >>> sure what you mean by that. IDP federation should be configured at the >>> realm level and really has nothing to do with applications. >>> >>> I'm really happy that somebody is doing this. We're getting a real >>> impressive feature set! >> >> Sure. What I meant was that the application only knows about KC tokens >> nothing else. It will always receive a KC token regardless the protocol used >> to authenticate the user against a 3rd party IdP (saml, oidc, whatever). The >> example I gave was about an user trying to authenticate against a SAML IdP. >> In this case, after a successful authentication on the IdP, the IdP will >> issue a token to KC. Then KC will validate the token, perform trust and >> security checks, do user provisioning and attribute/claim resolution to >> finally issue a KC token and redirect the user to the application. If the >> app is configured to use openid in KC then it will receive a openid token >> from KC, not saml ... >> >> The other scenario is pretty much the same. The difference is that KC will >> not issue its own token but just replay the token issued by the 3rd party >> IdP to the service provider. >> >> I agree that this config goes at the realm level. For instance, to create and >> enable providers for being used. However, I think we would need some >> specific configuration for applications as well. Specially when defining >> default roles, mapping attributes. Another example of application config is >> when using a OIDC/oAuth IdP. You may want to define scopes per-application. >> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 2 December, 2014 12:34:45 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker You shouldn't have icon images for social providers. They should be specified as part of the theme in CSS as is now. ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Bill Burke" <bburke(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, 2 December, 2014 12:22:21 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > Hi, > > Anyone know where I can get the icons images for social providers ? It > seems zocial defines them encoded in some way in CSS. I need that to > provide default images if user does not specify their own. > > Or is still possible to use zocial ones ? > > Regards. > > ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Bill Burke" <bburke(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Thursday, November 27, 2014 9:01:38 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > Hi guys, > > I've done some initial work covering both persistence and brokering. No > UI, yet. I'm focused on the model, rest api and brokering functionality > for now. > > What I have is enough to decide if we are aligned about this > functionality. So you can understand how the model (and persistence), > rest api and brokering functionality looks like. Can we schedule a > meeting ? > > Btw, my branch is here [1]. > > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Thursday, November 20, 2014 2:48:49 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > Currently adapters can only make authz decisions (@RolesAllowed) based > on either realm roles or the roles of one specific application. This is > related to 1) too. > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: > > 1) Sounds like something definitely worth aiming for. > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > >> I just wanted to quickly list the additional work we discussed so > >> everyone > >> can think about it (in no particular order): > >> > >> 1) Mapping of tokens - how do we deal with mapping of an external token > >> to > >> a KC token? For example an external token with attribute 'group' that > >> contains 'sales' and 'manager' could be mapped to 'manager' role for > >> 'sales app in a KC token. Could we use Drools? This could also be used > >> in > >> user federation to allow more complex mapping of roles/groups than a > >> simple 1-1 > >> 2) Retrieving tokens - if an application wants to retrieve the external > >> token (for example to view Facebook friends if user logged in with > >> Facebook) > >> 3) Configure scope - currently for social we only request a very limited > >> scope (basic profile and email), to for example view Facebook friends > >> we'd need to ask for that as well > >> 4) Selecting provider - currently in social (and for first pass of > >> brokering) we have an icon user has to select, but can we select the > >> provider in a different way (for example ask user for email, and select > >> based on email domain) > >> 5) Gateway - don't create a KC token, but just forward the external > >> token > >> > >> IMO 1) is a killer feature, as it would allow companies to add external > >> users without having to modify their applications. Issue with 5) is that > >> applications need to understand more than one token, which would require > >> rewriting applications. > >> > >> This work is also somewhat related to other authentication mechanisms > >> (for > >> example Kerberos ticket, LDAP and passwordless). > >> > >> ----- Original Message ----- > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > >>> Cc: keycloak-dev(a)lists.jboss.org > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication > >>> Broker > >>> > >>> ----- Original Message ----- > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > >>>> To: keycloak-dev(a)lists.jboss.org > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM > >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication > >>>> Broker > >>>> > >>>> > >>>> > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > >>>>> Hi, > >>>>> > >>>>> Would like to start a discussion about how to enable KC as an > >>>>> Authentication Broker in order to supported Chained Federation > >>>>> and > >>>>> also Identity Federation. First of all, some background about > >>>>> what > >>>>> this is all about. > >>>>> > >>>>> Currently KeyCloak provides two basic types of authentication > >>>>> (correct > >>>>> me if I'm wrong, please): > >>>>> > >>>>> 1) Local authentication (based on some credential type > >>>>> enabled > >>>>> to > >>>>> a realm) > >>>>> 2) Social authentication > >>>>> > >>>>> Local authentication is about authenticating the user locally > >>>>> using > >>>>> KC's own identity store. Nothing special here. And Social > >>>>> Authentication which allows users to choose the Social IdP > >>>>> they > >>>>> want > >>>>> to authenticate with. In this case, the IdP is always one of > >>>>> the > >>>>> built-in social providers supported by KC such as Facebook, > >>>>> Google, > >>>>> Twitter, Github and so forth. > >>>>> > >>>>> When doing social, the user is automatically provisioned in KC > >>>>> identity store after a successful authentication. The user > >>>>> does > >>>>> not > >>>>> need to fill a registration form and can access the > >>>>> application > >>>>> very > >>>>> quickly. During the provisioning some basic information is > >>>>> retrieved > >>>>> from the social provider such as email, firstname and so > >>>>> forth. > >>>>> These > >>>>> are very basic information, any other information such as > >>>>> those > >>>>> related with authorization policies - eg.: roles and groups - > >>>>> must > >>>>> be > >>>>> defined later via KC's admin console. > >>>>> > >>>>> Another important characteristic of social authentication is > >>>>> that > >>>>> the > >>>>> application receives a KC token and not the token that was > >>>>> issued by > >>>>> the social IdP during the authentication process. If the > >>>>> application > >>>>> wants to consume resources from the resource provider he was > >>>>> authenticated it must obtain the access token(again) by itself > >>>>> prior > >>>>> to invoke the resource provider API. Assuming all those social > >>>>> providers are based on oAuth 1.0 or 2.0. > >>>>> > >>>>> That said, the Authentication Broker functionality aims to > >>>>> cover > >>>>> the > >>>>> same use cases but with a lot of more flexibility on how you > >>>>> setup > >>>>> identity providers(not only social ones) and the different > >>>>> federation > >>>>> protocols they may support such as SAML, OpenID, oAuth and so > >>>>> forth. > >>>>> This is useful when an enterprise is providing services to > >>>>> different > >>>>> customers(IdP) and does not want to manage many to many > >>>>> relationships. When using a broker, the authentication steps > >>>>> are > >>>>> pretty much the same when you are using social authentication, > >>>>> with > >>>>> important differences on how you support different identity > >>>>> providers, different federation protocols, how users are > >>>>> provisioned > >>>>> and how claims and attributes are resolved. > >>>>> > >>>>> The brokering functionality can be done in two ways depending > >>>>> if > >>>>> the > >>>>> broker service is acting as a gateway or not. When acting as a > >>>>> gateway, the broker will respond to the application the same > >>>>> token > >>>>> issued by the trusted identity provider. For instance, if the > >>>>> user > >>>>> selects a SAML IdP to authenticate with, the application will > >>>>> receive > >>>>> a SAML Response. In this case, the application must also be > >>>>> prepared > >>>>> to handle a specific federation protocol. > >>>>> > >>>>> However, the broker service can also be used to completely > >>>>> abstract > >>>>> from the application the protocol used to authenticate an > >>>>> user. > >>>>> In > >>>>> this case, the application will just receive an ordinary KC > >>>>> token > >>>>> after a successful authentication. > >>>>> > >>>>> In both cases, the broker acts as an intermediary where > >>>>> specific > >>>>> security policies can be applied when users try to > >>>>> authenticate > >>>>> themselves against a 3rd party IdP. That brings a lot of value > >>>>> when > >>>>> you think about auditing, authorization and how users are > >>>>> provisioned > >>>>> when federation of identities is needed. This also allows > >>>>> existing > >>>>> security infrastructures (eg.: SAML-based infrastructures) to > >>>>> benefit > >>>>> from KC's support for cloud, rest and mobile use cases. > >>>>> > >>>>> I think this is enough to start a discussion. I've an initial > >>>>> discussion with Stian about all that and we agreed that > >>>>> abstract > >>>>> the > >>>>> protocol from applications should be prioritized. The main > >>>>> reason is > >>>>> that it makes life easier for applications so they only need > >>>>> to > >>>>> know > >>>>> about KC tokens and nothing else. However that brings some new > >>>>> requirements around user provisioning and claim/attribute > >>>>> resolution > >>>>> or mapping. But that would be another thread. > >>>>> > >>>> > >>>> Can you elaborate on "abstract the protocol from applications"? Not > >>>> sure what you mean by that. IDP federation should be configured at > >>>> the > >>>> realm level and really has nothing to do with applications. > >>>> > >>>> I'm really happy that somebody is doing this. We're getting a real > >>>> impressive feature set! > >>> > >>> Sure. What I meant was that the application only knows about KC tokens > >>> nothing else. It will always receive a KC token regardless the protocol > >>> used > >>> to authenticate the user against a 3rd party IdP (saml, oidc, > >>> whatever). > >>> The > >>> example I gave was about an user trying to authenticate against a SAML > >>> IdP. > >>> In this case, after a successful authentication on the IdP, the IdP > >>> will > >>> issue a token to KC. Then KC will validate the token, perform trust and > >>> security checks, do user provisioning and attribute/claim resolution to > >>> finally issue a KC token and redirect the user to the application. If > >>> the > >>> app is configured to use openid in KC then it will receive a openid > >>> token > >>> from KC, not saml ... > >>> > >>> The other scenario is pretty much the same. The difference is that KC > >>> will > >>> not issue its own token but just replay the token issued by the 3rd > >>> party > >>> IdP to the service provider. > >>> > >>> I agree that this config goes at the realm level. For instance, to > >>> create > >>> and > >>> enable providers for being used. However, I think we would need some > >>> specific configuration for applications as well. Specially when > >>> defining > >>> default roles, mapping attributes. Another example of application > >>> config > >>> is > >>> when using a OIDC/oAuth IdP. You may want to define scopes > >>> per-application. > >>> > >>>> > >>>> -- > >>>> Bill Burke > >>>> JBoss, a division of Red Hat > >>>> http://bill.burkecentral.com > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > > > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 2 December, 2014 12:55:21 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker Users can now specify a Icon Url to be rendered on the login page when social or any other identity provider is configured. So we just load the image the url entered by the user. Are you saying that users should change the theme or customize css if they only want to change an icon for a provider ?

----- Original Message ----- From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, December 2, 2014 9:42:15 AM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker All look and feel related things including images and stylesheets should be part of themes. This is to allow customizing them in the theme. Also, an image is not the correct way to render a button, it should be defined in CSS. ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, 2 December, 2014 12:34:45 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > You shouldn't have icon images for social providers. They should be > specified > as part of the theme in CSS as is now. > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > Hi, > > > > Anyone know where I can get the icons images for social providers ? > > It > > seems zocial defines them encoded in some way in CSS. I need that to > > provide default images if user does not specify their own. > > > > Or is still possible to use zocial ones ? > > > > Regards. > > > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Thursday, November 27, 2014 9:01:38 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > Hi guys, > > > > I've done some initial work covering both persistence and brokering. > > No > > UI, yet. I'm focused on the model, rest api and brokering > > functionality > > for now. > > > > What I have is enough to decide if we are aligned about this > > functionality. So you can understand how the model (and persistence), > > rest api and brokering functionality looks like. Can we schedule a > > meeting ? > > > > Btw, my branch is here [1]. > > > > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > Regards. > > Pedro Igor > > > > ----- Original Message ----- > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > To: keycloak-dev(a)lists.jboss.org > > Sent: Thursday, November 20, 2014 2:48:49 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > Currently adapters can only make authz decisions (@RolesAllowed) based > > on either realm roles or the roles of one specific application. This is > > related to 1) too. > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: > > > 1) Sounds like something definitely worth aiming for. > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > > >> I just wanted to quickly list the additional work we discussed so > > >> everyone > > >> can think about it (in no particular order): > > >> > > >> 1) Mapping of tokens - how do we deal with mapping of an external > > >> token > > >> to > > >> a KC token? For example an external token with attribute 'group' that > > >> contains 'sales' and 'manager' could be mapped to 'manager' role for > > >> 'sales app in a KC token. Could we use Drools? This could also be used > > >> in > > >> user federation to allow more complex mapping of roles/groups than a > > >> simple 1-1 > > >> 2) Retrieving tokens - if an application wants to retrieve the > > >> external > > >> token (for example to view Facebook friends if user logged in with > > >> Facebook) > > >> 3) Configure scope - currently for social we only request a very > > >> limited > > >> scope (basic profile and email), to for example view Facebook friends > > >> we'd need to ask for that as well > > >> 4) Selecting provider - currently in social (and for first pass of > > >> brokering) we have an icon user has to select, but can we select the > > >> provider in a different way (for example ask user for email, and > > >> select > > >> based on email domain) > > >> 5) Gateway - don't create a KC token, but just forward the external > > >> token > > >> > > >> IMO 1) is a killer feature, as it would allow companies to add > > >> external > > >> users without having to modify their applications. Issue with 5) is > > >> that > > >> applications need to understand more than one token, which would > > >> require > > >> rewriting applications. > > >> > > >> This work is also somewhat related to other authentication mechanisms > > >> (for > > >> example Kerberos ticket, LDAP and passwordless). > > >> > > >> ----- Original Message ----- > > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > >>> Cc: keycloak-dev(a)lists.jboss.org > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication > > >>> Broker > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > >>>> To: keycloak-dev(a)lists.jboss.org > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM > > >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication > > >>>> Broker > > >>>> > > >>>> > > >>>> > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > > >>>>> Hi, > > >>>>> > > >>>>> Would like to start a discussion about how to enable KC as > > >>>>> an > > >>>>> Authentication Broker in order to supported Chained > > >>>>> Federation > > >>>>> and > > >>>>> also Identity Federation. First of all, some background > > >>>>> about > > >>>>> what > > >>>>> this is all about. > > >>>>> > > >>>>> Currently KeyCloak provides two basic types of > > >>>>> authentication > > >>>>> (correct > > >>>>> me if I'm wrong, please): > > >>>>> > > >>>>> 1) Local authentication (based on some credential type > > >>>>> enabled > > >>>>> to > > >>>>> a realm) > > >>>>> 2) Social authentication > > >>>>> > > >>>>> Local authentication is about authenticating the user > > >>>>> locally > > >>>>> using > > >>>>> KC's own identity store. Nothing special here. And Social > > >>>>> Authentication which allows users to choose the Social IdP > > >>>>> they > > >>>>> want > > >>>>> to authenticate with. In this case, the IdP is always one of > > >>>>> the > > >>>>> built-in social providers supported by KC such as Facebook, > > >>>>> Google, > > >>>>> Twitter, Github and so forth. > > >>>>> > > >>>>> When doing social, the user is automatically provisioned in > > >>>>> KC > > >>>>> identity store after a successful authentication. The user > > >>>>> does > > >>>>> not > > >>>>> need to fill a registration form and can access the > > >>>>> application > > >>>>> very > > >>>>> quickly. During the provisioning some basic information is > > >>>>> retrieved > > >>>>> from the social provider such as email, firstname and so > > >>>>> forth. > > >>>>> These > > >>>>> are very basic information, any other information such as > > >>>>> those > > >>>>> related with authorization policies - eg.: roles and groups > > >>>>> - > > >>>>> must > > >>>>> be > > >>>>> defined later via KC's admin console. > > >>>>> > > >>>>> Another important characteristic of social authentication is > > >>>>> that > > >>>>> the > > >>>>> application receives a KC token and not the token that was > > >>>>> issued by > > >>>>> the social IdP during the authentication process. If the > > >>>>> application > > >>>>> wants to consume resources from the resource provider he was > > >>>>> authenticated it must obtain the access token(again) by > > >>>>> itself > > >>>>> prior > > >>>>> to invoke the resource provider API. Assuming all those > > >>>>> social > > >>>>> providers are based on oAuth 1.0 or 2.0. > > >>>>> > > >>>>> That said, the Authentication Broker functionality aims to > > >>>>> cover > > >>>>> the > > >>>>> same use cases but with a lot of more flexibility on how you > > >>>>> setup > > >>>>> identity providers(not only social ones) and the different > > >>>>> federation > > >>>>> protocols they may support such as SAML, OpenID, oAuth and > > >>>>> so > > >>>>> forth. > > >>>>> This is useful when an enterprise is providing services to > > >>>>> different > > >>>>> customers(IdP) and does not want to manage many to many > > >>>>> relationships. When using a broker, the authentication steps > > >>>>> are > > >>>>> pretty much the same when you are using social > > >>>>> authentication, > > >>>>> with > > >>>>> important differences on how you support different identity > > >>>>> providers, different federation protocols, how users are > > >>>>> provisioned > > >>>>> and how claims and attributes are resolved. > > >>>>> > > >>>>> The brokering functionality can be done in two ways > > >>>>> depending > > >>>>> if > > >>>>> the > > >>>>> broker service is acting as a gateway or not. When acting as > > >>>>> a > > >>>>> gateway, the broker will respond to the application the same > > >>>>> token > > >>>>> issued by the trusted identity provider. For instance, if > > >>>>> the > > >>>>> user > > >>>>> selects a SAML IdP to authenticate with, the application > > >>>>> will > > >>>>> receive > > >>>>> a SAML Response. In this case, the application must also be > > >>>>> prepared > > >>>>> to handle a specific federation protocol. > > >>>>> > > >>>>> However, the broker service can also be used to completely > > >>>>> abstract > > >>>>> from the application the protocol used to authenticate an > > >>>>> user. > > >>>>> In > > >>>>> this case, the application will just receive an ordinary KC > > >>>>> token > > >>>>> after a successful authentication. > > >>>>> > > >>>>> In both cases, the broker acts as an intermediary where > > >>>>> specific > > >>>>> security policies can be applied when users try to > > >>>>> authenticate > > >>>>> themselves against a 3rd party IdP. That brings a lot of > > >>>>> value > > >>>>> when > > >>>>> you think about auditing, authorization and how users are > > >>>>> provisioned > > >>>>> when federation of identities is needed. This also allows > > >>>>> existing > > >>>>> security infrastructures (eg.: SAML-based infrastructures) > > >>>>> to > > >>>>> benefit > > >>>>> from KC's support for cloud, rest and mobile use cases. > > >>>>> > > >>>>> I think this is enough to start a discussion. I've an > > >>>>> initial > > >>>>> discussion with Stian about all that and we agreed that > > >>>>> abstract > > >>>>> the > > >>>>> protocol from applications should be prioritized. The main > > >>>>> reason is > > >>>>> that it makes life easier for applications so they only need > > >>>>> to > > >>>>> know > > >>>>> about KC tokens and nothing else. However that brings some > > >>>>> new > > >>>>> requirements around user provisioning and claim/attribute > > >>>>> resolution > > >>>>> or mapping. But that would be another thread. > > >>>>> > > >>>> > > >>>> Can you elaborate on "abstract the protocol from applications"? Not > > >>>> sure what you mean by that. IDP federation should be configured at > > >>>> the > > >>>> realm level and really has nothing to do with applications. > > >>>> > > >>>> I'm really happy that somebody is doing this. We're getting a real > > >>>> impressive feature set! > > >>> > > >>> Sure. What I meant was that the application only knows about KC > > >>> tokens > > >>> nothing else. It will always receive a KC token regardless the > > >>> protocol > > >>> used > > >>> to authenticate the user against a 3rd party IdP (saml, oidc, > > >>> whatever). > > >>> The > > >>> example I gave was about an user trying to authenticate against a > > >>> SAML > > >>> IdP. > > >>> In this case, after a successful authentication on the IdP, the IdP > > >>> will > > >>> issue a token to KC. Then KC will validate the token, perform trust > > >>> and > > >>> security checks, do user provisioning and attribute/claim resolution > > >>> to > > >>> finally issue a KC token and redirect the user to the application. If > > >>> the > > >>> app is configured to use openid in KC then it will receive a openid > > >>> token > > >>> from KC, not saml ... > > >>> > > >>> The other scenario is pretty much the same. The difference is that KC > > >>> will > > >>> not issue its own token but just replay the token issued by the 3rd > > >>> party > > >>> IdP to the service provider. > > >>> > > >>> I agree that this config goes at the realm level. For instance, to > > >>> create > > >>> and > > >>> enable providers for being used. However, I think we would need some > > >>> specific configuration for applications as well. Specially when > > >>> defining > > >>> default roles, mapping attributes. Another example of application > > >>> config > > >>> is > > >>> when using a OIDC/oAuth IdP. You may want to define scopes > > >>> per-application. > > >>> > > >>>> > > >>>> -- > > >>>> Bill Burke > > >>>> JBoss, a division of Red Hat > > >>>> http://bill.burkecentral.com > > >>>> _______________________________________________ > > >>>> keycloak-dev mailing list > > >>>> keycloak-dev(a)lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >>>> > > >>> _______________________________________________ > > >>> keycloak-dev mailing list > > >>> keycloak-dev(a)lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >>> > > >> _______________________________________________ > > >> keycloak-dev mailing list > > >> keycloak-dev(a)lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > > > > > > > > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 2 December, 2014 1:13:08 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker I'll go for it then. Will remove the icon url from the model and leave that for users if they want to provide icons for their identity providers. My point is that icons can be usually served by the same server/application or proxy, so download images are not such a big deal. Also, the icon url is part of the freemarker model and people can do what ever they want with it. What I think will also help in your future plans.

----- Original Message ----- From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, December 2, 2014 10:04:33 AM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, 2 December, 2014 12:55:21 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > Users can now specify a Icon Url to be rendered on the login page when > social > or any other identity provider is configured. So we just load the image the > url entered by the user. > > Are you saying that users should change the theme or customize css if they > only want to change an icon for a provider ? Yes, there's many issues with having a icon url: * Won't work for internationalization - we don't have this now, but we will * Image is not a good button - CSS is much better * Doesn't support themes - we allow users to switch l&f by switching themes, but that won't work for a icon url. In the future we may also support multiple themes per-realm, for example to depending on the devices (one theme for mobiles, one for desktops, etc) * Requires the URL to be hosted somewhere - why require a separate call to download an image (to a separate server maybe) if it can simply be defined in a single CSS file? Rather than add additional places to define look and feel components we should in the future make it easier to add/customize themes. > > ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, December 2, 2014 9:42:15 AM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > All look and feel related things including images and stylesheets should be > part of themes. This is to allow customizing them in the theme. Also, an > image is not the correct way to render a button, it should be defined in > CSS. > > ----- Original Message ----- > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > You shouldn't have icon images for social providers. They should be > > specified > > as part of the theme in CSS as is now. > > > > ----- Original Message ----- > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > Hi, > > > > > > Anyone know where I can get the icons images for social providers ? > > > It > > > seems zocial defines them encoded in some way in CSS. I need that > > > to > > > provide default images if user does not specify their own. > > > > > > Or is still possible to use zocial ones ? > > > > > > Regards. > > > > > > ----- Original Message ----- > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Thursday, November 27, 2014 9:01:38 PM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > Hi guys, > > > > > > I've done some initial work covering both persistence and brokering. > > > No > > > UI, yet. I'm focused on the model, rest api and brokering > > > functionality > > > for now. > > > > > > What I have is enough to decide if we are aligned about this > > > functionality. So you can understand how the model (and > > > persistence), > > > rest api and brokering functionality looks like. Can we schedule a > > > meeting ? > > > > > > Btw, my branch is here [1]. > > > > > > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > Regards. > > > Pedro Igor > > > > > > ----- Original Message ----- > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > To: keycloak-dev(a)lists.jboss.org > > > Sent: Thursday, November 20, 2014 2:48:49 PM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > Currently adapters can only make authz decisions (@RolesAllowed) based > > > on either realm roles or the roles of one specific application. This > > > is > > > related to 1) too. > > > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: > > > > 1) Sounds like something definitely worth aiming for. > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > > > >> I just wanted to quickly list the additional work we discussed so > > > >> everyone > > > >> can think about it (in no particular order): > > > >> > > > >> 1) Mapping of tokens - how do we deal with mapping of an external > > > >> token > > > >> to > > > >> a KC token? For example an external token with attribute 'group' > > > >> that > > > >> contains 'sales' and 'manager' could be mapped to 'manager' role for > > > >> 'sales app in a KC token. Could we use Drools? This could also be > > > >> used > > > >> in > > > >> user federation to allow more complex mapping of roles/groups than a > > > >> simple 1-1 > > > >> 2) Retrieving tokens - if an application wants to retrieve the > > > >> external > > > >> token (for example to view Facebook friends if user logged in with > > > >> Facebook) > > > >> 3) Configure scope - currently for social we only request a very > > > >> limited > > > >> scope (basic profile and email), to for example view Facebook > > > >> friends > > > >> we'd need to ask for that as well > > > >> 4) Selecting provider - currently in social (and for first pass of > > > >> brokering) we have an icon user has to select, but can we select the > > > >> provider in a different way (for example ask user for email, and > > > >> select > > > >> based on email domain) > > > >> 5) Gateway - don't create a KC token, but just forward the external > > > >> token > > > >> > > > >> IMO 1) is a killer feature, as it would allow companies to add > > > >> external > > > >> users without having to modify their applications. Issue with 5) is > > > >> that > > > >> applications need to understand more than one token, which would > > > >> require > > > >> rewriting applications. > > > >> > > > >> This work is also somewhat related to other authentication > > > >> mechanisms > > > >> (for > > > >> example Kerberos ticket, LDAP and passwordless). > > > >> > > > >> ----- Original Message ----- > > > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > > > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > >>> Broker > > > >>> > > > >>> ----- Original Message ----- > > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > >>>> Broker > > > >>>> > > > >>>> > > > >>>> > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > > > >>>>> Hi, > > > >>>>> > > > >>>>> Would like to start a discussion about how to enable KC as > > > >>>>> an > > > >>>>> Authentication Broker in order to supported Chained > > > >>>>> Federation > > > >>>>> and > > > >>>>> also Identity Federation. First of all, some background > > > >>>>> about > > > >>>>> what > > > >>>>> this is all about. > > > >>>>> > > > >>>>> Currently KeyCloak provides two basic types of > > > >>>>> authentication > > > >>>>> (correct > > > >>>>> me if I'm wrong, please): > > > >>>>> > > > >>>>> 1) Local authentication (based on some credential type > > > >>>>> enabled > > > >>>>> to > > > >>>>> a realm) > > > >>>>> 2) Social authentication > > > >>>>> > > > >>>>> Local authentication is about authenticating the user > > > >>>>> locally > > > >>>>> using > > > >>>>> KC's own identity store. Nothing special here. And Social > > > >>>>> Authentication which allows users to choose the Social IdP > > > >>>>> they > > > >>>>> want > > > >>>>> to authenticate with. In this case, the IdP is always one > > > >>>>> of > > > >>>>> the > > > >>>>> built-in social providers supported by KC such as > > > >>>>> Facebook, > > > >>>>> Google, > > > >>>>> Twitter, Github and so forth. > > > >>>>> > > > >>>>> When doing social, the user is automatically provisioned > > > >>>>> in > > > >>>>> KC > > > >>>>> identity store after a successful authentication. The user > > > >>>>> does > > > >>>>> not > > > >>>>> need to fill a registration form and can access the > > > >>>>> application > > > >>>>> very > > > >>>>> quickly. During the provisioning some basic information is > > > >>>>> retrieved > > > >>>>> from the social provider such as email, firstname and so > > > >>>>> forth. > > > >>>>> These > > > >>>>> are very basic information, any other information such as > > > >>>>> those > > > >>>>> related with authorization policies - eg.: roles and > > > >>>>> groups > > > >>>>> - > > > >>>>> must > > > >>>>> be > > > >>>>> defined later via KC's admin console. > > > >>>>> > > > >>>>> Another important characteristic of social authentication > > > >>>>> is > > > >>>>> that > > > >>>>> the > > > >>>>> application receives a KC token and not the token that was > > > >>>>> issued by > > > >>>>> the social IdP during the authentication process. If the > > > >>>>> application > > > >>>>> wants to consume resources from the resource provider he > > > >>>>> was > > > >>>>> authenticated it must obtain the access token(again) by > > > >>>>> itself > > > >>>>> prior > > > >>>>> to invoke the resource provider API. Assuming all those > > > >>>>> social > > > >>>>> providers are based on oAuth 1.0 or 2.0. > > > >>>>> > > > >>>>> That said, the Authentication Broker functionality aims to > > > >>>>> cover > > > >>>>> the > > > >>>>> same use cases but with a lot of more flexibility on how > > > >>>>> you > > > >>>>> setup > > > >>>>> identity providers(not only social ones) and the different > > > >>>>> federation > > > >>>>> protocols they may support such as SAML, OpenID, oAuth and > > > >>>>> so > > > >>>>> forth. > > > >>>>> This is useful when an enterprise is providing services to > > > >>>>> different > > > >>>>> customers(IdP) and does not want to manage many to many > > > >>>>> relationships. When using a broker, the authentication > > > >>>>> steps > > > >>>>> are > > > >>>>> pretty much the same when you are using social > > > >>>>> authentication, > > > >>>>> with > > > >>>>> important differences on how you support different > > > >>>>> identity > > > >>>>> providers, different federation protocols, how users are > > > >>>>> provisioned > > > >>>>> and how claims and attributes are resolved. > > > >>>>> > > > >>>>> The brokering functionality can be done in two ways > > > >>>>> depending > > > >>>>> if > > > >>>>> the > > > >>>>> broker service is acting as a gateway or not. When acting > > > >>>>> as > > > >>>>> a > > > >>>>> gateway, the broker will respond to the application the > > > >>>>> same > > > >>>>> token > > > >>>>> issued by the trusted identity provider. For instance, if > > > >>>>> the > > > >>>>> user > > > >>>>> selects a SAML IdP to authenticate with, the application > > > >>>>> will > > > >>>>> receive > > > >>>>> a SAML Response. In this case, the application must also > > > >>>>> be > > > >>>>> prepared > > > >>>>> to handle a specific federation protocol. > > > >>>>> > > > >>>>> However, the broker service can also be used to completely > > > >>>>> abstract > > > >>>>> from the application the protocol used to authenticate an > > > >>>>> user. > > > >>>>> In > > > >>>>> this case, the application will just receive an ordinary > > > >>>>> KC > > > >>>>> token > > > >>>>> after a successful authentication. > > > >>>>> > > > >>>>> In both cases, the broker acts as an intermediary where > > > >>>>> specific > > > >>>>> security policies can be applied when users try to > > > >>>>> authenticate > > > >>>>> themselves against a 3rd party IdP. That brings a lot of > > > >>>>> value > > > >>>>> when > > > >>>>> you think about auditing, authorization and how users are > > > >>>>> provisioned > > > >>>>> when federation of identities is needed. This also allows > > > >>>>> existing > > > >>>>> security infrastructures (eg.: SAML-based infrastructures) > > > >>>>> to > > > >>>>> benefit > > > >>>>> from KC's support for cloud, rest and mobile use cases. > > > >>>>> > > > >>>>> I think this is enough to start a discussion. I've an > > > >>>>> initial > > > >>>>> discussion with Stian about all that and we agreed that > > > >>>>> abstract > > > >>>>> the > > > >>>>> protocol from applications should be prioritized. The main > > > >>>>> reason is > > > >>>>> that it makes life easier for applications so they only > > > >>>>> need > > > >>>>> to > > > >>>>> know > > > >>>>> about KC tokens and nothing else. However that brings some > > > >>>>> new > > > >>>>> requirements around user provisioning and claim/attribute > > > >>>>> resolution > > > >>>>> or mapping. But that would be another thread. > > > >>>>> > > > >>>> > > > >>>> Can you elaborate on "abstract the protocol from applications"? > > > >>>> Not > > > >>>> sure what you mean by that. IDP federation should be configured > > > >>>> at > > > >>>> the > > > >>>> realm level and really has nothing to do with applications. > > > >>>> > > > >>>> I'm really happy that somebody is doing this. We're getting a > > > >>>> real > > > >>>> impressive feature set! > > > >>> > > > >>> Sure. What I meant was that the application only knows about KC > > > >>> tokens > > > >>> nothing else. It will always receive a KC token regardless the > > > >>> protocol > > > >>> used > > > >>> to authenticate the user against a 3rd party IdP (saml, oidc, > > > >>> whatever). > > > >>> The > > > >>> example I gave was about an user trying to authenticate against a > > > >>> SAML > > > >>> IdP. > > > >>> In this case, after a successful authentication on the IdP, the IdP > > > >>> will > > > >>> issue a token to KC. Then KC will validate the token, perform trust > > > >>> and > > > >>> security checks, do user provisioning and attribute/claim > > > >>> resolution > > > >>> to > > > >>> finally issue a KC token and redirect the user to the application. > > > >>> If > > > >>> the > > > >>> app is configured to use openid in KC then it will receive a openid > > > >>> token > > > >>> from KC, not saml ... > > > >>> > > > >>> The other scenario is pretty much the same. The difference is that > > > >>> KC > > > >>> will > > > >>> not issue its own token but just replay the token issued by the 3rd > > > >>> party > > > >>> IdP to the service provider. > > > >>> > > > >>> I agree that this config goes at the realm level. For instance, to > > > >>> create > > > >>> and > > > >>> enable providers for being used. However, I think we would need > > > >>> some > > > >>> specific configuration for applications as well. Specially when > > > >>> defining > > > >>> default roles, mapping attributes. Another example of application > > > >>> config > > > >>> is > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes > > > >>> per-application. > > > >>> > > > >>>> > > > >>>> -- > > > >>>> Bill Burke > > > >>>> JBoss, a division of Red Hat > > > >>>> http://bill.burkecentral.com > > > >>>> _______________________________________________ > > > >>>> keycloak-dev mailing list > > > >>>> keycloak-dev(a)lists.jboss.org > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >>>> > > > >>> _______________________________________________ > > > >>> keycloak-dev mailing list > > > >>> keycloak-dev(a)lists.jboss.org > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >>> > > > >> _______________________________________________ > > > >> keycloak-dev mailing list > > > >> keycloak-dev(a)lists.jboss.org > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > >> > > > > > > > > > > > > > > > > > > -- > > > Bill Burke > > > JBoss, a division of Red Hat > > > http://bill.burkecentral.com > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, December 2, 2014 10:23:24 AM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, 2 December, 2014 1:13:08 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > I'll go for it then. Will remove the icon url from the model and leave that > for users if they want to provide icons for their identity providers. > > My point is that icons can be usually served by the same server/application > or proxy, so download images are not such a big deal. Also, the icon url is > part of the freemarker model and people can do what ever they want with it. > What I think will also help in your future plans. I'm not following. Are you saying that if a named image 'my-provider.png' is loaded from a theme, then you can override it in another theme? If so, that's basically the same as having a css class 'my-provider' in a theme. With the exception that with an image you end up with having to require a image per provider per theme per language, which could be a lot of images for a single provider. Also, buttons for accessibility should be defined with text and css, not images that can't be interpreted. You also still need to modify the theme, so I don't see any benefits.

> > ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, December 2, 2014 10:04:33 AM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Tuesday, 2 December, 2014 12:55:21 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > Users can now specify a Icon Url to be rendered on the login page when > > social > > or any other identity provider is configured. So we just load the image > > the > > url entered by the user. > > > > Are you saying that users should change the theme or customize css if > > they > > only want to change an icon for a provider ? > > Yes, there's many issues with having a icon url: > > * Won't work for internationalization - we don't have this now, but we will > * Image is not a good button - CSS is much better > * Doesn't support themes - we allow users to switch l&f by switching > themes, > but that won't work for a icon url. In the future we may also support > multiple themes per-realm, for example to depending on the devices (one > theme for mobiles, one for desktops, etc) > * Requires the URL to be hosted somewhere - why require a separate call to > download an image (to a separate server maybe) if it can simply be defined > in a single CSS file? > > Rather than add additional places to define look and feel components we > should in the future make it easier to add/customize themes. > > > > > ----- Original Message ----- > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Tuesday, December 2, 2014 9:42:15 AM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > All look and feel related things including images and stylesheets should > > be > > part of themes. This is to allow customizing them in the theme. Also, an > > image is not the correct way to render a button, it should be defined in > > CSS. > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > You shouldn't have icon images for social providers. They should be > > > specified > > > as part of the theme in CSS as is now. > > > > > > ----- Original Message ----- > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > Hi, > > > > > > > > Anyone know where I can get the icons images for social providers > > > > ? > > > > It > > > > seems zocial defines them encoded in some way in CSS. I need that > > > > to > > > > provide default images if user does not specify their own. > > > > > > > > Or is still possible to use zocial ones ? > > > > > > > > Regards. > > > > > > > > ----- Original Message ----- > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Thursday, November 27, 2014 9:01:38 PM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > Hi guys, > > > > > > > > I've done some initial work covering both persistence and > > > > brokering. > > > > No > > > > UI, yet. I'm focused on the model, rest api and brokering > > > > functionality > > > > for now. > > > > > > > > What I have is enough to decide if we are aligned about this > > > > functionality. So you can understand how the model (and > > > > persistence), > > > > rest api and brokering functionality looks like. Can we schedule a > > > > meeting ? > > > > > > > > Btw, my branch is here [1]. > > > > > > > > [1] https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > > > Regards. > > > > Pedro Igor > > > > > > > > ----- Original Message ----- > > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > To: keycloak-dev(a)lists.jboss.org > > > > Sent: Thursday, November 20, 2014 2:48:49 PM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > Currently adapters can only make authz decisions (@RolesAllowed) > > > > based > > > > on either realm roles or the roles of one specific application. This > > > > is > > > > related to 1) too. > > > > > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: > > > > > 1) Sounds like something definitely worth aiming for. > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > > > > >> I just wanted to quickly list the additional work we discussed so > > > > >> everyone > > > > >> can think about it (in no particular order): > > > > >> > > > > >> 1) Mapping of tokens - how do we deal with mapping of an external > > > > >> token > > > > >> to > > > > >> a KC token? For example an external token with attribute 'group' > > > > >> that > > > > >> contains 'sales' and 'manager' could be mapped to 'manager' role > > > > >> for > > > > >> 'sales app in a KC token. Could we use Drools? This could also be > > > > >> used > > > > >> in > > > > >> user federation to allow more complex mapping of roles/groups than > > > > >> a > > > > >> simple 1-1 > > > > >> 2) Retrieving tokens - if an application wants to retrieve the > > > > >> external > > > > >> token (for example to view Facebook friends if user logged in with > > > > >> Facebook) > > > > >> 3) Configure scope - currently for social we only request a very > > > > >> limited > > > > >> scope (basic profile and email), to for example view Facebook > > > > >> friends > > > > >> we'd need to ask for that as well > > > > >> 4) Selecting provider - currently in social (and for first pass of > > > > >> brokering) we have an icon user has to select, but can we select > > > > >> the > > > > >> provider in a different way (for example ask user for email, and > > > > >> select > > > > >> based on email domain) > > > > >> 5) Gateway - don't create a KC token, but just forward the > > > > >> external > > > > >> token > > > > >> > > > > >> IMO 1) is a killer feature, as it would allow companies to add > > > > >> external > > > > >> users without having to modify their applications. Issue with 5) > > > > >> is > > > > >> that > > > > >> applications need to understand more than one token, which would > > > > >> require > > > > >> rewriting applications. > > > > >> > > > > >> This work is also somewhat related to other authentication > > > > >> mechanisms > > > > >> (for > > > > >> example Kerberos ticket, LDAP and passwordless). > > > > >> > > > > >> ----- Original Message ----- > > > > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > >>> Broker > > > > >>> > > > > >>> ----- Original Message ----- > > > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and > > > > >>>> Authentication > > > > >>>> Broker > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > > > > >>>>> Hi, > > > > >>>>> > > > > >>>>> Would like to start a discussion about how to enable KC > > > > >>>>> as > > > > >>>>> an > > > > >>>>> Authentication Broker in order to supported Chained > > > > >>>>> Federation > > > > >>>>> and > > > > >>>>> also Identity Federation. First of all, some background > > > > >>>>> about > > > > >>>>> what > > > > >>>>> this is all about. > > > > >>>>> > > > > >>>>> Currently KeyCloak provides two basic types of > > > > >>>>> authentication > > > > >>>>> (correct > > > > >>>>> me if I'm wrong, please): > > > > >>>>> > > > > >>>>> 1) Local authentication (based on some credential > > > > >>>>> type > > > > >>>>> enabled > > > > >>>>> to > > > > >>>>> a realm) > > > > >>>>> 2) Social authentication > > > > >>>>> > > > > >>>>> Local authentication is about authenticating the user > > > > >>>>> locally > > > > >>>>> using > > > > >>>>> KC's own identity store. Nothing special here. And > > > > >>>>> Social > > > > >>>>> Authentication which allows users to choose the Social > > > > >>>>> IdP > > > > >>>>> they > > > > >>>>> want > > > > >>>>> to authenticate with. In this case, the IdP is always > > > > >>>>> one > > > > >>>>> of > > > > >>>>> the > > > > >>>>> built-in social providers supported by KC such as > > > > >>>>> Facebook, > > > > >>>>> Google, > > > > >>>>> Twitter, Github and so forth. > > > > >>>>> > > > > >>>>> When doing social, the user is automatically provisioned > > > > >>>>> in > > > > >>>>> KC > > > > >>>>> identity store after a successful authentication. The > > > > >>>>> user > > > > >>>>> does > > > > >>>>> not > > > > >>>>> need to fill a registration form and can access the > > > > >>>>> application > > > > >>>>> very > > > > >>>>> quickly. During the provisioning some basic information > > > > >>>>> is > > > > >>>>> retrieved > > > > >>>>> from the social provider such as email, firstname and so > > > > >>>>> forth. > > > > >>>>> These > > > > >>>>> are very basic information, any other information such > > > > >>>>> as > > > > >>>>> those > > > > >>>>> related with authorization policies - eg.: roles and > > > > >>>>> groups > > > > >>>>> - > > > > >>>>> must > > > > >>>>> be > > > > >>>>> defined later via KC's admin console. > > > > >>>>> > > > > >>>>> Another important characteristic of social > > > > >>>>> authentication > > > > >>>>> is > > > > >>>>> that > > > > >>>>> the > > > > >>>>> application receives a KC token and not the token that > > > > >>>>> was > > > > >>>>> issued by > > > > >>>>> the social IdP during the authentication process. If the > > > > >>>>> application > > > > >>>>> wants to consume resources from the resource provider he > > > > >>>>> was > > > > >>>>> authenticated it must obtain the access token(again) by > > > > >>>>> itself > > > > >>>>> prior > > > > >>>>> to invoke the resource provider API. Assuming all those > > > > >>>>> social > > > > >>>>> providers are based on oAuth 1.0 or 2.0. > > > > >>>>> > > > > >>>>> That said, the Authentication Broker functionality aims > > > > >>>>> to > > > > >>>>> cover > > > > >>>>> the > > > > >>>>> same use cases but with a lot of more flexibility on how > > > > >>>>> you > > > > >>>>> setup > > > > >>>>> identity providers(not only social ones) and the > > > > >>>>> different > > > > >>>>> federation > > > > >>>>> protocols they may support such as SAML, OpenID, oAuth > > > > >>>>> and > > > > >>>>> so > > > > >>>>> forth. > > > > >>>>> This is useful when an enterprise is providing services > > > > >>>>> to > > > > >>>>> different > > > > >>>>> customers(IdP) and does not want to manage many to many > > > > >>>>> relationships. When using a broker, the authentication > > > > >>>>> steps > > > > >>>>> are > > > > >>>>> pretty much the same when you are using social > > > > >>>>> authentication, > > > > >>>>> with > > > > >>>>> important differences on how you support different > > > > >>>>> identity > > > > >>>>> providers, different federation protocols, how users are > > > > >>>>> provisioned > > > > >>>>> and how claims and attributes are resolved. > > > > >>>>> > > > > >>>>> The brokering functionality can be done in two ways > > > > >>>>> depending > > > > >>>>> if > > > > >>>>> the > > > > >>>>> broker service is acting as a gateway or not. When > > > > >>>>> acting > > > > >>>>> as > > > > >>>>> a > > > > >>>>> gateway, the broker will respond to the application the > > > > >>>>> same > > > > >>>>> token > > > > >>>>> issued by the trusted identity provider. For instance, > > > > >>>>> if > > > > >>>>> the > > > > >>>>> user > > > > >>>>> selects a SAML IdP to authenticate with, the application > > > > >>>>> will > > > > >>>>> receive > > > > >>>>> a SAML Response. In this case, the application must also > > > > >>>>> be > > > > >>>>> prepared > > > > >>>>> to handle a specific federation protocol. > > > > >>>>> > > > > >>>>> However, the broker service can also be used to > > > > >>>>> completely > > > > >>>>> abstract > > > > >>>>> from the application the protocol used to authenticate > > > > >>>>> an > > > > >>>>> user. > > > > >>>>> In > > > > >>>>> this case, the application will just receive an ordinary > > > > >>>>> KC > > > > >>>>> token > > > > >>>>> after a successful authentication. > > > > >>>>> > > > > >>>>> In both cases, the broker acts as an intermediary where > > > > >>>>> specific > > > > >>>>> security policies can be applied when users try to > > > > >>>>> authenticate > > > > >>>>> themselves against a 3rd party IdP. That brings a lot of > > > > >>>>> value > > > > >>>>> when > > > > >>>>> you think about auditing, authorization and how users > > > > >>>>> are > > > > >>>>> provisioned > > > > >>>>> when federation of identities is needed. This also > > > > >>>>> allows > > > > >>>>> existing > > > > >>>>> security infrastructures (eg.: SAML-based > > > > >>>>> infrastructures) > > > > >>>>> to > > > > >>>>> benefit > > > > >>>>> from KC's support for cloud, rest and mobile use cases. > > > > >>>>> > > > > >>>>> I think this is enough to start a discussion. I've an > > > > >>>>> initial > > > > >>>>> discussion with Stian about all that and we agreed that > > > > >>>>> abstract > > > > >>>>> the > > > > >>>>> protocol from applications should be prioritized. The > > > > >>>>> main > > > > >>>>> reason is > > > > >>>>> that it makes life easier for applications so they only > > > > >>>>> need > > > > >>>>> to > > > > >>>>> know > > > > >>>>> about KC tokens and nothing else. However that brings > > > > >>>>> some > > > > >>>>> new > > > > >>>>> requirements around user provisioning and > > > > >>>>> claim/attribute > > > > >>>>> resolution > > > > >>>>> or mapping. But that would be another thread. > > > > >>>>> > > > > >>>> > > > > >>>> Can you elaborate on "abstract the protocol from applications"? > > > > >>>> Not > > > > >>>> sure what you mean by that. IDP federation should be configured > > > > >>>> at > > > > >>>> the > > > > >>>> realm level and really has nothing to do with applications. > > > > >>>> > > > > >>>> I'm really happy that somebody is doing this. We're getting a > > > > >>>> real > > > > >>>> impressive feature set! > > > > >>> > > > > >>> Sure. What I meant was that the application only knows about KC > > > > >>> tokens > > > > >>> nothing else. It will always receive a KC token regardless the > > > > >>> protocol > > > > >>> used > > > > >>> to authenticate the user against a 3rd party IdP (saml, oidc, > > > > >>> whatever). > > > > >>> The > > > > >>> example I gave was about an user trying to authenticate against a > > > > >>> SAML > > > > >>> IdP. > > > > >>> In this case, after a successful authentication on the IdP, the > > > > >>> IdP > > > > >>> will > > > > >>> issue a token to KC. Then KC will validate the token, perform > > > > >>> trust > > > > >>> and > > > > >>> security checks, do user provisioning and attribute/claim > > > > >>> resolution > > > > >>> to > > > > >>> finally issue a KC token and redirect the user to the > > > > >>> application. > > > > >>> If > > > > >>> the > > > > >>> app is configured to use openid in KC then it will receive a > > > > >>> openid > > > > >>> token > > > > >>> from KC, not saml ... > > > > >>> > > > > >>> The other scenario is pretty much the same. The difference is > > > > >>> that > > > > >>> KC > > > > >>> will > > > > >>> not issue its own token but just replay the token issued by the > > > > >>> 3rd > > > > >>> party > > > > >>> IdP to the service provider. > > > > >>> > > > > >>> I agree that this config goes at the realm level. For instance, > > > > >>> to > > > > >>> create > > > > >>> and > > > > >>> enable providers for being used. However, I think we would need > > > > >>> some > > > > >>> specific configuration for applications as well. Specially when > > > > >>> defining > > > > >>> default roles, mapping attributes. Another example of application > > > > >>> config > > > > >>> is > > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes > > > > >>> per-application. > > > > >>> > > > > >>>> > > > > >>>> -- > > > > >>>> Bill Burke > > > > >>>> JBoss, a division of Red Hat > > > > >>>> http://bill.burkecentral.com > > > > >>>> _______________________________________________ > > > > >>>> keycloak-dev mailing list > > > > >>>> keycloak-dev(a)lists.jboss.org > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > >>>> > > > > >>> _______________________________________________ > > > > >>> keycloak-dev mailing list > > > > >>> keycloak-dev(a)lists.jboss.org > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > >>> > > > > >> _______________________________________________ > > > > >> keycloak-dev mailing list > > > > >> keycloak-dev(a)lists.jboss.org > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > >> > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Bill Burke > > > > JBoss, a division of Red Hat > > > > http://bill.burkecentral.com > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, 5 December, 2014 2:29:37 AM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker Hi, Social has a button to enable/disable it. I'm wondering what to do with the brokered identity providers. Shall we add a similar flag for that ? I was also wondering if the best would be a flag in a per provider basis. So we can disable/enable a specific provider (social or brokered), instead of doing that for all. Regards. Pedro Igor ----- Original Message ----- From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, December 2, 2014 10:42:11 AM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, December 2, 2014 10:23:24 AM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Tuesday, 2 December, 2014 1:13:08 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > I'll go for it then. Will remove the icon url from the model and leave > > that > > for users if they want to provide icons for their identity providers. > > > > My point is that icons can be usually served by the same > > server/application > > or proxy, so download images are not such a big deal. Also, the icon url > > is > > part of the freemarker model and people can do what ever they want with > > it. > > What I think will also help in your future plans. > > I'm not following. Are you saying that if a named image 'my-provider.png' > is > loaded from a theme, then you can override it in another theme? > > If so, that's basically the same as having a css class 'my-provider' in a > theme. With the exception that with an image you end up with having to > require a image per provider per theme per language, which could be a lot > of > images for a single provider. Also, buttons for accessibility should be > defined with text and css, not images that can't be interpreted. You also > still need to modify the theme, so I don't see any benefits. You are right. Having a icon url per provider does not makes sense if there are requirements to change images accordingly to a theme or language. CSS makes life easier. Will remove that property from the model. > > > > > ----- Original Message ----- > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Tuesday, December 2, 2014 10:04:33 AM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > > > ----- Original Message ----- > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > Users can now specify a Icon Url to be rendered on the login page when > > > social > > > or any other identity provider is configured. So we just load the image > > > the > > > url entered by the user. > > > > > > Are you saying that users should change the theme or customize css if > > > they > > > only want to change an icon for a provider ? > > > > Yes, there's many issues with having a icon url: > > > > * Won't work for internationalization - we don't have this now, but we > > will > > * Image is not a good button - CSS is much better > > * Doesn't support themes - we allow users to switch l&f by switching > > themes, > > but that won't work for a icon url. In the future we may also support > > multiple themes per-realm, for example to depending on the devices (one > > theme for mobiles, one for desktops, etc) > > * Requires the URL to be hosted somewhere - why require a separate call > > to > > download an image (to a separate server maybe) if it can simply be > > defined > > in a single CSS file? > > > > Rather than add additional places to define look and feel components we > > should in the future make it easier to add/customize themes. > > > > > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Tuesday, December 2, 2014 9:42:15 AM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > All look and feel related things including images and stylesheets > > > should > > > be > > > part of themes. This is to allow customizing them in the theme. Also, > > > an > > > image is not the correct way to render a button, it should be defined > > > in > > > CSS. > > > > > > ----- Original Message ----- > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > You shouldn't have icon images for social providers. They should be > > > > specified > > > > as part of the theme in CSS as is now. > > > > > > > > ----- Original Message ----- > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > Hi, > > > > > > > > > > Anyone know where I can get the icons images for social > > > > > providers > > > > > ? > > > > > It > > > > > seems zocial defines them encoded in some way in CSS. I need > > > > > that > > > > > to > > > > > provide default images if user does not specify their own. > > > > > > > > > > Or is still possible to use zocial ones ? > > > > > > > > > > Regards. > > > > > > > > > > ----- Original Message ----- > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > Hi guys, > > > > > > > > > > I've done some initial work covering both persistence and > > > > > brokering. > > > > > No > > > > > UI, yet. I'm focused on the model, rest api and brokering > > > > > functionality > > > > > for now. > > > > > > > > > > What I have is enough to decide if we are aligned about this > > > > > functionality. So you can understand how the model (and > > > > > persistence), > > > > > rest api and brokering functionality looks like. Can we schedule > > > > > a > > > > > meeting ? > > > > > > > > > > Btw, my branch is here [1]. > > > > > > > > > > [1] > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > > > > > Regards. > > > > > Pedro Igor > > > > > > > > > > ----- Original Message ----- > > > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > To: keycloak-dev(a)lists.jboss.org > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > Currently adapters can only make authz decisions (@RolesAllowed) > > > > > based > > > > > on either realm roles or the roles of one specific application. > > > > > This > > > > > is > > > > > related to 1) too. > > > > > > > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: > > > > > > 1) Sounds like something definitely worth aiming for. > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > > > > > >> I just wanted to quickly list the additional work we discussed > > > > > >> so > > > > > >> everyone > > > > > >> can think about it (in no particular order): > > > > > >> > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an > > > > > >> external > > > > > >> token > > > > > >> to > > > > > >> a KC token? For example an external token with attribute 'group' > > > > > >> that > > > > > >> contains 'sales' and 'manager' could be mapped to 'manager' role > > > > > >> for > > > > > >> 'sales app in a KC token. Could we use Drools? This could also > > > > > >> be > > > > > >> used > > > > > >> in > > > > > >> user federation to allow more complex mapping of roles/groups > > > > > >> than > > > > > >> a > > > > > >> simple 1-1 > > > > > >> 2) Retrieving tokens - if an application wants to retrieve the > > > > > >> external > > > > > >> token (for example to view Facebook friends if user logged in > > > > > >> with > > > > > >> Facebook) > > > > > >> 3) Configure scope - currently for social we only request a very > > > > > >> limited > > > > > >> scope (basic profile and email), to for example view Facebook > > > > > >> friends > > > > > >> we'd need to ask for that as well > > > > > >> 4) Selecting provider - currently in social (and for first pass > > > > > >> of > > > > > >> brokering) we have an icon user has to select, but can we select > > > > > >> the > > > > > >> provider in a different way (for example ask user for email, and > > > > > >> select > > > > > >> based on email domain) > > > > > >> 5) Gateway - don't create a KC token, but just forward the > > > > > >> external > > > > > >> token > > > > > >> > > > > > >> IMO 1) is a killer feature, as it would allow companies to add > > > > > >> external > > > > > >> users without having to modify their applications. Issue with 5) > > > > > >> is > > > > > >> that > > > > > >> applications need to understand more than one token, which would > > > > > >> require > > > > > >> rewriting applications. > > > > > >> > > > > > >> This work is also somewhat related to other authentication > > > > > >> mechanisms > > > > > >> (for > > > > > >> example Kerberos ticket, LDAP and passwordless). > > > > > >> > > > > > >> ----- Original Message ----- > > > > > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and > > > > > >>> Authentication > > > > > >>> Broker > > > > > >>> > > > > > >>> ----- Original Message ----- > > > > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and > > > > > >>>> Authentication > > > > > >>>> Broker > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > > > > > >>>>> Hi, > > > > > >>>>> > > > > > >>>>> Would like to start a discussion about how to enable > > > > > >>>>> KC > > > > > >>>>> as > > > > > >>>>> an > > > > > >>>>> Authentication Broker in order to supported Chained > > > > > >>>>> Federation > > > > > >>>>> and > > > > > >>>>> also Identity Federation. First of all, some > > > > > >>>>> background > > > > > >>>>> about > > > > > >>>>> what > > > > > >>>>> this is all about. > > > > > >>>>> > > > > > >>>>> Currently KeyCloak provides two basic types of > > > > > >>>>> authentication > > > > > >>>>> (correct > > > > > >>>>> me if I'm wrong, please): > > > > > >>>>> > > > > > >>>>> 1) Local authentication (based on some credential > > > > > >>>>> type > > > > > >>>>> enabled > > > > > >>>>> to > > > > > >>>>> a realm) > > > > > >>>>> 2) Social authentication > > > > > >>>>> > > > > > >>>>> Local authentication is about authenticating the user > > > > > >>>>> locally > > > > > >>>>> using > > > > > >>>>> KC's own identity store. Nothing special here. And > > > > > >>>>> Social > > > > > >>>>> Authentication which allows users to choose the Social > > > > > >>>>> IdP > > > > > >>>>> they > > > > > >>>>> want > > > > > >>>>> to authenticate with. In this case, the IdP is always > > > > > >>>>> one > > > > > >>>>> of > > > > > >>>>> the > > > > > >>>>> built-in social providers supported by KC such as > > > > > >>>>> Facebook, > > > > > >>>>> Google, > > > > > >>>>> Twitter, Github and so forth. > > > > > >>>>> > > > > > >>>>> When doing social, the user is automatically > > > > > >>>>> provisioned > > > > > >>>>> in > > > > > >>>>> KC > > > > > >>>>> identity store after a successful authentication. The > > > > > >>>>> user > > > > > >>>>> does > > > > > >>>>> not > > > > > >>>>> need to fill a registration form and can access the > > > > > >>>>> application > > > > > >>>>> very > > > > > >>>>> quickly. During the provisioning some basic > > > > > >>>>> information > > > > > >>>>> is > > > > > >>>>> retrieved > > > > > >>>>> from the social provider such as email, firstname and > > > > > >>>>> so > > > > > >>>>> forth. > > > > > >>>>> These > > > > > >>>>> are very basic information, any other information such > > > > > >>>>> as > > > > > >>>>> those > > > > > >>>>> related with authorization policies - eg.: roles and > > > > > >>>>> groups > > > > > >>>>> - > > > > > >>>>> must > > > > > >>>>> be > > > > > >>>>> defined later via KC's admin console. > > > > > >>>>> > > > > > >>>>> Another important characteristic of social > > > > > >>>>> authentication > > > > > >>>>> is > > > > > >>>>> that > > > > > >>>>> the > > > > > >>>>> application receives a KC token and not the token that > > > > > >>>>> was > > > > > >>>>> issued by > > > > > >>>>> the social IdP during the authentication process. If > > > > > >>>>> the > > > > > >>>>> application > > > > > >>>>> wants to consume resources from the resource provider > > > > > >>>>> he > > > > > >>>>> was > > > > > >>>>> authenticated it must obtain the access token(again) > > > > > >>>>> by > > > > > >>>>> itself > > > > > >>>>> prior > > > > > >>>>> to invoke the resource provider API. Assuming all > > > > > >>>>> those > > > > > >>>>> social > > > > > >>>>> providers are based on oAuth 1.0 or 2.0. > > > > > >>>>> > > > > > >>>>> That said, the Authentication Broker functionality > > > > > >>>>> aims > > > > > >>>>> to > > > > > >>>>> cover > > > > > >>>>> the > > > > > >>>>> same use cases but with a lot of more flexibility on > > > > > >>>>> how > > > > > >>>>> you > > > > > >>>>> setup > > > > > >>>>> identity providers(not only social ones) and the > > > > > >>>>> different > > > > > >>>>> federation > > > > > >>>>> protocols they may support such as SAML, OpenID, oAuth > > > > > >>>>> and > > > > > >>>>> so > > > > > >>>>> forth. > > > > > >>>>> This is useful when an enterprise is providing > > > > > >>>>> services > > > > > >>>>> to > > > > > >>>>> different > > > > > >>>>> customers(IdP) and does not want to manage many to > > > > > >>>>> many > > > > > >>>>> relationships. When using a broker, the authentication > > > > > >>>>> steps > > > > > >>>>> are > > > > > >>>>> pretty much the same when you are using social > > > > > >>>>> authentication, > > > > > >>>>> with > > > > > >>>>> important differences on how you support different > > > > > >>>>> identity > > > > > >>>>> providers, different federation protocols, how users > > > > > >>>>> are > > > > > >>>>> provisioned > > > > > >>>>> and how claims and attributes are resolved. > > > > > >>>>> > > > > > >>>>> The brokering functionality can be done in two ways > > > > > >>>>> depending > > > > > >>>>> if > > > > > >>>>> the > > > > > >>>>> broker service is acting as a gateway or not. When > > > > > >>>>> acting > > > > > >>>>> as > > > > > >>>>> a > > > > > >>>>> gateway, the broker will respond to the application > > > > > >>>>> the > > > > > >>>>> same > > > > > >>>>> token > > > > > >>>>> issued by the trusted identity provider. For instance, > > > > > >>>>> if > > > > > >>>>> the > > > > > >>>>> user > > > > > >>>>> selects a SAML IdP to authenticate with, the > > > > > >>>>> application > > > > > >>>>> will > > > > > >>>>> receive > > > > > >>>>> a SAML Response. In this case, the application must > > > > > >>>>> also > > > > > >>>>> be > > > > > >>>>> prepared > > > > > >>>>> to handle a specific federation protocol. > > > > > >>>>> > > > > > >>>>> However, the broker service can also be used to > > > > > >>>>> completely > > > > > >>>>> abstract > > > > > >>>>> from the application the protocol used to authenticate > > > > > >>>>> an > > > > > >>>>> user. > > > > > >>>>> In > > > > > >>>>> this case, the application will just receive an > > > > > >>>>> ordinary > > > > > >>>>> KC > > > > > >>>>> token > > > > > >>>>> after a successful authentication. > > > > > >>>>> > > > > > >>>>> In both cases, the broker acts as an intermediary > > > > > >>>>> where > > > > > >>>>> specific > > > > > >>>>> security policies can be applied when users try to > > > > > >>>>> authenticate > > > > > >>>>> themselves against a 3rd party IdP. That brings a lot > > > > > >>>>> of > > > > > >>>>> value > > > > > >>>>> when > > > > > >>>>> you think about auditing, authorization and how users > > > > > >>>>> are > > > > > >>>>> provisioned > > > > > >>>>> when federation of identities is needed. This also > > > > > >>>>> allows > > > > > >>>>> existing > > > > > >>>>> security infrastructures (eg.: SAML-based > > > > > >>>>> infrastructures) > > > > > >>>>> to > > > > > >>>>> benefit > > > > > >>>>> from KC's support for cloud, rest and mobile use > > > > > >>>>> cases. > > > > > >>>>> > > > > > >>>>> I think this is enough to start a discussion. I've an > > > > > >>>>> initial > > > > > >>>>> discussion with Stian about all that and we agreed > > > > > >>>>> that > > > > > >>>>> abstract > > > > > >>>>> the > > > > > >>>>> protocol from applications should be prioritized. The > > > > > >>>>> main > > > > > >>>>> reason is > > > > > >>>>> that it makes life easier for applications so they > > > > > >>>>> only > > > > > >>>>> need > > > > > >>>>> to > > > > > >>>>> know > > > > > >>>>> about KC tokens and nothing else. However that brings > > > > > >>>>> some > > > > > >>>>> new > > > > > >>>>> requirements around user provisioning and > > > > > >>>>> claim/attribute > > > > > >>>>> resolution > > > > > >>>>> or mapping. But that would be another thread. > > > > > >>>>> > > > > > >>>> > > > > > >>>> Can you elaborate on "abstract the protocol from > > > > > >>>> applications"? > > > > > >>>> Not > > > > > >>>> sure what you mean by that. IDP federation should be > > > > > >>>> configured > > > > > >>>> at > > > > > >>>> the > > > > > >>>> realm level and really has nothing to do with applications. > > > > > >>>> > > > > > >>>> I'm really happy that somebody is doing this. We're getting a > > > > > >>>> real > > > > > >>>> impressive feature set! > > > > > >>> > > > > > >>> Sure. What I meant was that the application only knows about KC > > > > > >>> tokens > > > > > >>> nothing else. It will always receive a KC token regardless the > > > > > >>> protocol > > > > > >>> used > > > > > >>> to authenticate the user against a 3rd party IdP (saml, oidc, > > > > > >>> whatever). > > > > > >>> The > > > > > >>> example I gave was about an user trying to authenticate against > > > > > >>> a > > > > > >>> SAML > > > > > >>> IdP. > > > > > >>> In this case, after a successful authentication on the IdP, the > > > > > >>> IdP > > > > > >>> will > > > > > >>> issue a token to KC. Then KC will validate the token, perform > > > > > >>> trust > > > > > >>> and > > > > > >>> security checks, do user provisioning and attribute/claim > > > > > >>> resolution > > > > > >>> to > > > > > >>> finally issue a KC token and redirect the user to the > > > > > >>> application. > > > > > >>> If > > > > > >>> the > > > > > >>> app is configured to use openid in KC then it will receive a > > > > > >>> openid > > > > > >>> token > > > > > >>> from KC, not saml ... > > > > > >>> > > > > > >>> The other scenario is pretty much the same. The difference is > > > > > >>> that > > > > > >>> KC > > > > > >>> will > > > > > >>> not issue its own token but just replay the token issued by the > > > > > >>> 3rd > > > > > >>> party > > > > > >>> IdP to the service provider. > > > > > >>> > > > > > >>> I agree that this config goes at the realm level. For instance, > > > > > >>> to > > > > > >>> create > > > > > >>> and > > > > > >>> enable providers for being used. However, I think we would need > > > > > >>> some > > > > > >>> specific configuration for applications as well. Specially when > > > > > >>> defining > > > > > >>> default roles, mapping attributes. Another example of > > > > > >>> application > > > > > >>> config > > > > > >>> is > > > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes > > > > > >>> per-application. > > > > > >>> > > > > > >>>> > > > > > >>>> -- > > > > > >>>> Bill Burke > > > > > >>>> JBoss, a division of Red Hat > > > > > >>>> http://bill.burkecentral.com > > > > > >>>> _______________________________________________ > > > > > >>>> keycloak-dev mailing list > > > > > >>>> keycloak-dev(a)lists.jboss.org > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > >>>> > > > > > >>> _______________________________________________ > > > > > >>> keycloak-dev mailing list > > > > > >>> keycloak-dev(a)lists.jboss.org > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > >>> > > > > > >> _______________________________________________ > > > > > >> keycloak-dev mailing list > > > > > >> keycloak-dev(a)lists.jboss.org > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Bill Burke > > > > > JBoss, a division of Red Hat > > > > > http://bill.burkecentral.com > > > > > _______________________________________________ > > > > > keycloak-dev mailing list > > > > > keycloak-dev(a)lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > _______________________________________________ > > > > > keycloak-dev mailing list > > > > > keycloak-dev(a)lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > _______________________________________________ > > > > > keycloak-dev mailing list > > > > > keycloak-dev(a)lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, December 5, 2014 10:22:10 AM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker Looks good. I reckon we can combine the two pages. What about if the 'Add provider' drop-down is: OpenID SAML ------ Google GitHub Facebook Twitter Let's drop social on/off and instead have a enable/disable button on each provider.

Also, would be nice if users could set a name or alias for a provider instance. This would make the callback url easier to use (instead of callback/<UUID> it's callback/<alias>). The user federation providers have this.

----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, 5 December, 2014 1:08:53 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > In one of our last discussions, you suggested to leave Social as it is. > Although IMO I think we can have a single place to manage both social and > user-defined identity providers. Social ones are just OOTB and > pre-configured identity providers now. > > That said, today I'm using separated tabs for social and user-defined. > Please, take a look at [1] for more details on how the UI looks like. > > I've changed social UI a bit in order to provide a specific page for > create/update. I've also added a "Show Secret" link to display the > client_secret in clear text if user wants to. > > Beside the enable/disable button, I think another good thing to do is > specify > a default role(s) for each provider. That can be useful if applications > want > to perform any kind of authorization based on the identity provider or > authentication method used to authenticate an user (eg.: useful for > adaptative or multi-level access control). We can also use the "amr" claim > in the ID Token, which seems KC is not considering at all. The latter is an > important thing to think of, regardless this broker work I'm doing. > > [1] > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sha... > > ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, December 5, 2014 6:15:15 AM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > Having a separate enable/disable for each provider would be good. If you're > leaving the social tab as is and adding a separate tab for configuring > brokered idp's then we should leave the social enable/disable button, > otherwise it depends how it'll look like in the end. > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Friday, 5 December, 2014 2:29:37 AM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > Hi, > > > > Social has a button to enable/disable it. I'm wondering what to do > > with > > the brokered identity providers. Shall we add a similar flag for that > > ? > > > > I was also wondering if the best would be a flag in a per provider > > basis. > > So we can disable/enable a specific provider (social or brokered), > > instead of doing that for all. > > > > Regards. > > Pedro Igor > > > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Tuesday, December 2, 2014 10:42:11 AM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Tuesday, December 2, 2014 10:23:24 AM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > I'll go for it then. Will remove the icon url from the model and > > > > leave > > > > that > > > > for users if they want to provide icons for their identity providers. > > > > > > > > My point is that icons can be usually served by the same > > > > server/application > > > > or proxy, so download images are not such a big deal. Also, the icon > > > > url > > > > is > > > > part of the freemarker model and people can do what ever they want > > > > with > > > > it. > > > > What I think will also help in your future plans. > > > > > > I'm not following. Are you saying that if a named image > > > 'my-provider.png' > > > is > > > loaded from a theme, then you can override it in another theme? > > > > > > If so, that's basically the same as having a css class 'my-provider' in > > > a > > > theme. With the exception that with an image you end up with having to > > > require a image per provider per theme per language, which could be a > > > lot > > > of > > > images for a single provider. Also, buttons for accessibility should be > > > defined with text and css, not images that can't be interpreted. You > > > also > > > still need to modify the theme, so I don't see any benefits. > > > > You are right. Having a icon url per provider does not makes sense if > > there > > are requirements to change images accordingly to a theme or language. CSS > > makes life easier. > > > > Will remove that property from the model. > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > Users can now specify a Icon Url to be rendered on the login page > > > > > when > > > > > social > > > > > or any other identity provider is configured. So we just load the > > > > > image > > > > > the > > > > > url entered by the user. > > > > > > > > > > Are you saying that users should change the theme or customize css > > > > > if > > > > > they > > > > > only want to change an icon for a provider ? > > > > > > > > Yes, there's many issues with having a icon url: > > > > > > > > * Won't work for internationalization - we don't have this now, but > > > > we > > > > will > > > > * Image is not a good button - CSS is much better > > > > * Doesn't support themes - we allow users to switch l&f by switching > > > > themes, > > > > but that won't work for a icon url. In the future we may also support > > > > multiple themes per-realm, for example to depending on the devices > > > > (one > > > > theme for mobiles, one for desktops, etc) > > > > * Requires the URL to be hosted somewhere - why require a separate > > > > call > > > > to > > > > download an image (to a separate server maybe) if it can simply be > > > > defined > > > > in a single CSS file? > > > > > > > > Rather than add additional places to define look and feel components > > > > we > > > > should in the future make it easier to add/customize themes. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > All look and feel related things including images and stylesheets > > > > > should > > > > > be > > > > > part of themes. This is to allow customizing them in the theme. > > > > > Also, > > > > > an > > > > > image is not the correct way to render a button, it should be > > > > > defined > > > > > in > > > > > CSS. > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > You shouldn't have icon images for social providers. They should > > > > > > be > > > > > > specified > > > > > > as part of the theme in CSS as is now. > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Anyone know where I can get the icons images for social > > > > > > > providers > > > > > > > ? > > > > > > > It > > > > > > > seems zocial defines them encoded in some way in CSS. I > > > > > > > need > > > > > > > that > > > > > > > to > > > > > > > provide default images if user does not specify their own. > > > > > > > > > > > > > > Or is still possible to use zocial ones ? > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > I've done some initial work covering both persistence and > > > > > > > brokering. > > > > > > > No > > > > > > > UI, yet. I'm focused on the model, rest api and brokering > > > > > > > functionality > > > > > > > for now. > > > > > > > > > > > > > > What I have is enough to decide if we are aligned about this > > > > > > > functionality. So you can understand how the model (and > > > > > > > persistence), > > > > > > > rest api and brokering functionality looks like. Can we > > > > > > > schedule > > > > > > > a > > > > > > > meeting ? > > > > > > > > > > > > > > Btw, my branch is here [1]. > > > > > > > > > > > > > > [1] > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > > > > > > > > > Regards. > > > > > > > Pedro Igor > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > To: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > Currently adapters can only make authz decisions > > > > > > > (@RolesAllowed) > > > > > > > based > > > > > > > on either realm roles or the roles of one specific application. > > > > > > > This > > > > > > > is > > > > > > > related to 1) too. > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: > > > > > > > > 1) Sounds like something definitely worth aiming for. > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > > > > > > > >> I just wanted to quickly list the additional work we > > > > > > > >> discussed > > > > > > > >> so > > > > > > > >> everyone > > > > > > > >> can think about it (in no particular order): > > > > > > > >> > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an > > > > > > > >> external > > > > > > > >> token > > > > > > > >> to > > > > > > > >> a KC token? For example an external token with attribute > > > > > > > >> 'group' > > > > > > > >> that > > > > > > > >> contains 'sales' and 'manager' could be mapped to 'manager' > > > > > > > >> role > > > > > > > >> for > > > > > > > >> 'sales app in a KC token. Could we use Drools? This could > > > > > > > >> also > > > > > > > >> be > > > > > > > >> used > > > > > > > >> in > > > > > > > >> user federation to allow more complex mapping of > > > > > > > >> roles/groups > > > > > > > >> than > > > > > > > >> a > > > > > > > >> simple 1-1 > > > > > > > >> 2) Retrieving tokens - if an application wants to retrieve > > > > > > > >> the > > > > > > > >> external > > > > > > > >> token (for example to view Facebook friends if user logged > > > > > > > >> in > > > > > > > >> with > > > > > > > >> Facebook) > > > > > > > >> 3) Configure scope - currently for social we only request a > > > > > > > >> very > > > > > > > >> limited > > > > > > > >> scope (basic profile and email), to for example view > > > > > > > >> Facebook > > > > > > > >> friends > > > > > > > >> we'd need to ask for that as well > > > > > > > >> 4) Selecting provider - currently in social (and for first > > > > > > > >> pass > > > > > > > >> of > > > > > > > >> brokering) we have an icon user has to select, but can we > > > > > > > >> select > > > > > > > >> the > > > > > > > >> provider in a different way (for example ask user for email, > > > > > > > >> and > > > > > > > >> select > > > > > > > >> based on email domain) > > > > > > > >> 5) Gateway - don't create a KC token, but just forward the > > > > > > > >> external > > > > > > > >> token > > > > > > > >> > > > > > > > >> IMO 1) is a killer feature, as it would allow companies to > > > > > > > >> add > > > > > > > >> external > > > > > > > >> users without having to modify their applications. Issue > > > > > > > >> with > > > > > > > >> 5) > > > > > > > >> is > > > > > > > >> that > > > > > > > >> applications need to understand more than one token, which > > > > > > > >> would > > > > > > > >> require > > > > > > > >> rewriting applications. > > > > > > > >> > > > > > > > >> This work is also somewhat related to other authentication > > > > > > > >> mechanisms > > > > > > > >> (for > > > > > > > >> example Kerberos ticket, LDAP and passwordless). > > > > > > > >> > > > > > > > >> ----- Original Message ----- > > > > > > > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > >>> Authentication > > > > > > > >>> Broker > > > > > > > >>> > > > > > > > >>> ----- Original Message ----- > > > > > > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > >>>> Authentication > > > > > > > >>>> Broker > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > > > > > > > >>>>> Hi, > > > > > > > >>>>> > > > > > > > >>>>> Would like to start a discussion about how to > > > > > > > >>>>> enable > > > > > > > >>>>> KC > > > > > > > >>>>> as > > > > > > > >>>>> an > > > > > > > >>>>> Authentication Broker in order to supported > > > > > > > >>>>> Chained > > > > > > > >>>>> Federation > > > > > > > >>>>> and > > > > > > > >>>>> also Identity Federation. First of all, some > > > > > > > >>>>> background > > > > > > > >>>>> about > > > > > > > >>>>> what > > > > > > > >>>>> this is all about. > > > > > > > >>>>> > > > > > > > >>>>> Currently KeyCloak provides two basic types of > > > > > > > >>>>> authentication > > > > > > > >>>>> (correct > > > > > > > >>>>> me if I'm wrong, please): > > > > > > > >>>>> > > > > > > > >>>>> 1) Local authentication (based on some > > > > > > > >>>>> credential > > > > > > > >>>>> type > > > > > > > >>>>> enabled > > > > > > > >>>>> to > > > > > > > >>>>> a realm) > > > > > > > >>>>> 2) Social authentication > > > > > > > >>>>> > > > > > > > >>>>> Local authentication is about authenticating the > > > > > > > >>>>> user > > > > > > > >>>>> locally > > > > > > > >>>>> using > > > > > > > >>>>> KC's own identity store. Nothing special here. And > > > > > > > >>>>> Social > > > > > > > >>>>> Authentication which allows users to choose the > > > > > > > >>>>> Social > > > > > > > >>>>> IdP > > > > > > > >>>>> they > > > > > > > >>>>> want > > > > > > > >>>>> to authenticate with. In this case, the IdP is > > > > > > > >>>>> always > > > > > > > >>>>> one > > > > > > > >>>>> of > > > > > > > >>>>> the > > > > > > > >>>>> built-in social providers supported by KC such as > > > > > > > >>>>> Facebook, > > > > > > > >>>>> Google, > > > > > > > >>>>> Twitter, Github and so forth. > > > > > > > >>>>> > > > > > > > >>>>> When doing social, the user is automatically > > > > > > > >>>>> provisioned > > > > > > > >>>>> in > > > > > > > >>>>> KC > > > > > > > >>>>> identity store after a successful authentication. > > > > > > > >>>>> The > > > > > > > >>>>> user > > > > > > > >>>>> does > > > > > > > >>>>> not > > > > > > > >>>>> need to fill a registration form and can access > > > > > > > >>>>> the > > > > > > > >>>>> application > > > > > > > >>>>> very > > > > > > > >>>>> quickly. During the provisioning some basic > > > > > > > >>>>> information > > > > > > > >>>>> is > > > > > > > >>>>> retrieved > > > > > > > >>>>> from the social provider such as email, firstname > > > > > > > >>>>> and > > > > > > > >>>>> so > > > > > > > >>>>> forth. > > > > > > > >>>>> These > > > > > > > >>>>> are very basic information, any other information > > > > > > > >>>>> such > > > > > > > >>>>> as > > > > > > > >>>>> those > > > > > > > >>>>> related with authorization policies - eg.: roles > > > > > > > >>>>> and > > > > > > > >>>>> groups > > > > > > > >>>>> - > > > > > > > >>>>> must > > > > > > > >>>>> be > > > > > > > >>>>> defined later via KC's admin console. > > > > > > > >>>>> > > > > > > > >>>>> Another important characteristic of social > > > > > > > >>>>> authentication > > > > > > > >>>>> is > > > > > > > >>>>> that > > > > > > > >>>>> the > > > > > > > >>>>> application receives a KC token and not the token > > > > > > > >>>>> that > > > > > > > >>>>> was > > > > > > > >>>>> issued by > > > > > > > >>>>> the social IdP during the authentication process. > > > > > > > >>>>> If > > > > > > > >>>>> the > > > > > > > >>>>> application > > > > > > > >>>>> wants to consume resources from the resource > > > > > > > >>>>> provider > > > > > > > >>>>> he > > > > > > > >>>>> was > > > > > > > >>>>> authenticated it must obtain the access > > > > > > > >>>>> token(again) > > > > > > > >>>>> by > > > > > > > >>>>> itself > > > > > > > >>>>> prior > > > > > > > >>>>> to invoke the resource provider API. Assuming all > > > > > > > >>>>> those > > > > > > > >>>>> social > > > > > > > >>>>> providers are based on oAuth 1.0 or 2.0. > > > > > > > >>>>> > > > > > > > >>>>> That said, the Authentication Broker functionality > > > > > > > >>>>> aims > > > > > > > >>>>> to > > > > > > > >>>>> cover > > > > > > > >>>>> the > > > > > > > >>>>> same use cases but with a lot of more flexibility > > > > > > > >>>>> on > > > > > > > >>>>> how > > > > > > > >>>>> you > > > > > > > >>>>> setup > > > > > > > >>>>> identity providers(not only social ones) and the > > > > > > > >>>>> different > > > > > > > >>>>> federation > > > > > > > >>>>> protocols they may support such as SAML, OpenID, > > > > > > > >>>>> oAuth > > > > > > > >>>>> and > > > > > > > >>>>> so > > > > > > > >>>>> forth. > > > > > > > >>>>> This is useful when an enterprise is providing > > > > > > > >>>>> services > > > > > > > >>>>> to > > > > > > > >>>>> different > > > > > > > >>>>> customers(IdP) and does not want to manage many to > > > > > > > >>>>> many > > > > > > > >>>>> relationships. When using a broker, the > > > > > > > >>>>> authentication > > > > > > > >>>>> steps > > > > > > > >>>>> are > > > > > > > >>>>> pretty much the same when you are using social > > > > > > > >>>>> authentication, > > > > > > > >>>>> with > > > > > > > >>>>> important differences on how you support different > > > > > > > >>>>> identity > > > > > > > >>>>> providers, different federation protocols, how > > > > > > > >>>>> users > > > > > > > >>>>> are > > > > > > > >>>>> provisioned > > > > > > > >>>>> and how claims and attributes are resolved. > > > > > > > >>>>> > > > > > > > >>>>> The brokering functionality can be done in two > > > > > > > >>>>> ways > > > > > > > >>>>> depending > > > > > > > >>>>> if > > > > > > > >>>>> the > > > > > > > >>>>> broker service is acting as a gateway or not. When > > > > > > > >>>>> acting > > > > > > > >>>>> as > > > > > > > >>>>> a > > > > > > > >>>>> gateway, the broker will respond to the > > > > > > > >>>>> application > > > > > > > >>>>> the > > > > > > > >>>>> same > > > > > > > >>>>> token > > > > > > > >>>>> issued by the trusted identity provider. For > > > > > > > >>>>> instance, > > > > > > > >>>>> if > > > > > > > >>>>> the > > > > > > > >>>>> user > > > > > > > >>>>> selects a SAML IdP to authenticate with, the > > > > > > > >>>>> application > > > > > > > >>>>> will > > > > > > > >>>>> receive > > > > > > > >>>>> a SAML Response. In this case, the application > > > > > > > >>>>> must > > > > > > > >>>>> also > > > > > > > >>>>> be > > > > > > > >>>>> prepared > > > > > > > >>>>> to handle a specific federation protocol. > > > > > > > >>>>> > > > > > > > >>>>> However, the broker service can also be used to > > > > > > > >>>>> completely > > > > > > > >>>>> abstract > > > > > > > >>>>> from the application the protocol used to > > > > > > > >>>>> authenticate > > > > > > > >>>>> an > > > > > > > >>>>> user. > > > > > > > >>>>> In > > > > > > > >>>>> this case, the application will just receive an > > > > > > > >>>>> ordinary > > > > > > > >>>>> KC > > > > > > > >>>>> token > > > > > > > >>>>> after a successful authentication. > > > > > > > >>>>> > > > > > > > >>>>> In both cases, the broker acts as an intermediary > > > > > > > >>>>> where > > > > > > > >>>>> specific > > > > > > > >>>>> security policies can be applied when users try to > > > > > > > >>>>> authenticate > > > > > > > >>>>> themselves against a 3rd party IdP. That brings a > > > > > > > >>>>> lot > > > > > > > >>>>> of > > > > > > > >>>>> value > > > > > > > >>>>> when > > > > > > > >>>>> you think about auditing, authorization and how > > > > > > > >>>>> users > > > > > > > >>>>> are > > > > > > > >>>>> provisioned > > > > > > > >>>>> when federation of identities is needed. This also > > > > > > > >>>>> allows > > > > > > > >>>>> existing > > > > > > > >>>>> security infrastructures (eg.: SAML-based > > > > > > > >>>>> infrastructures) > > > > > > > >>>>> to > > > > > > > >>>>> benefit > > > > > > > >>>>> from KC's support for cloud, rest and mobile use > > > > > > > >>>>> cases. > > > > > > > >>>>> > > > > > > > >>>>> I think this is enough to start a discussion. I've > > > > > > > >>>>> an > > > > > > > >>>>> initial > > > > > > > >>>>> discussion with Stian about all that and we agreed > > > > > > > >>>>> that > > > > > > > >>>>> abstract > > > > > > > >>>>> the > > > > > > > >>>>> protocol from applications should be prioritized. > > > > > > > >>>>> The > > > > > > > >>>>> main > > > > > > > >>>>> reason is > > > > > > > >>>>> that it makes life easier for applications so they > > > > > > > >>>>> only > > > > > > > >>>>> need > > > > > > > >>>>> to > > > > > > > >>>>> know > > > > > > > >>>>> about KC tokens and nothing else. However that > > > > > > > >>>>> brings > > > > > > > >>>>> some > > > > > > > >>>>> new > > > > > > > >>>>> requirements around user provisioning and > > > > > > > >>>>> claim/attribute > > > > > > > >>>>> resolution > > > > > > > >>>>> or mapping. But that would be another thread. > > > > > > > >>>>> > > > > > > > >>>> > > > > > > > >>>> Can you elaborate on "abstract the protocol from > > > > > > > >>>> applications"? > > > > > > > >>>> Not > > > > > > > >>>> sure what you mean by that. IDP federation should be > > > > > > > >>>> configured > > > > > > > >>>> at > > > > > > > >>>> the > > > > > > > >>>> realm level and really has nothing to do with > > > > > > > >>>> applications. > > > > > > > >>>> > > > > > > > >>>> I'm really happy that somebody is doing this. We're > > > > > > > >>>> getting > > > > > > > >>>> a > > > > > > > >>>> real > > > > > > > >>>> impressive feature set! > > > > > > > >>> > > > > > > > >>> Sure. What I meant was that the application only knows > > > > > > > >>> about > > > > > > > >>> KC > > > > > > > >>> tokens > > > > > > > >>> nothing else. It will always receive a KC token regardless > > > > > > > >>> the > > > > > > > >>> protocol > > > > > > > >>> used > > > > > > > >>> to authenticate the user against a 3rd party IdP (saml, > > > > > > > >>> oidc, > > > > > > > >>> whatever). > > > > > > > >>> The > > > > > > > >>> example I gave was about an user trying to authenticate > > > > > > > >>> against > > > > > > > >>> a > > > > > > > >>> SAML > > > > > > > >>> IdP. > > > > > > > >>> In this case, after a successful authentication on the IdP, > > > > > > > >>> the > > > > > > > >>> IdP > > > > > > > >>> will > > > > > > > >>> issue a token to KC. Then KC will validate the token, > > > > > > > >>> perform > > > > > > > >>> trust > > > > > > > >>> and > > > > > > > >>> security checks, do user provisioning and attribute/claim > > > > > > > >>> resolution > > > > > > > >>> to > > > > > > > >>> finally issue a KC token and redirect the user to the > > > > > > > >>> application. > > > > > > > >>> If > > > > > > > >>> the > > > > > > > >>> app is configured to use openid in KC then it will receive > > > > > > > >>> a > > > > > > > >>> openid > > > > > > > >>> token > > > > > > > >>> from KC, not saml ... > > > > > > > >>> > > > > > > > >>> The other scenario is pretty much the same. The difference > > > > > > > >>> is > > > > > > > >>> that > > > > > > > >>> KC > > > > > > > >>> will > > > > > > > >>> not issue its own token but just replay the token issued by > > > > > > > >>> the > > > > > > > >>> 3rd > > > > > > > >>> party > > > > > > > >>> IdP to the service provider. > > > > > > > >>> > > > > > > > >>> I agree that this config goes at the realm level. For > > > > > > > >>> instance, > > > > > > > >>> to > > > > > > > >>> create > > > > > > > >>> and > > > > > > > >>> enable providers for being used. However, I think we would > > > > > > > >>> need > > > > > > > >>> some > > > > > > > >>> specific configuration for applications as well. Specially > > > > > > > >>> when > > > > > > > >>> defining > > > > > > > >>> default roles, mapping attributes. Another example of > > > > > > > >>> application > > > > > > > >>> config > > > > > > > >>> is > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define scopes > > > > > > > >>> per-application. > > > > > > > >>> > > > > > > > >>>> > > > > > > > >>>> -- > > > > > > > >>>> Bill Burke > > > > > > > >>>> JBoss, a division of Red Hat > > > > > > > >>>> http://bill.burkecentral.com > > > > > > > >>>> _______________________________________________ > > > > > > > >>>> keycloak-dev mailing list > > > > > > > >>>> keycloak-dev(a)lists.jboss.org > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > >>>> > > > > > > > >>> _______________________________________________ > > > > > > > >>> keycloak-dev mailing list > > > > > > > >>> keycloak-dev(a)lists.jboss.org > > > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > >>> > > > > > > > >> _______________________________________________ > > > > > > > >> keycloak-dev mailing list > > > > > > > >> keycloak-dev(a)lists.jboss.org > > > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Bill Burke > > > > > > > JBoss, a division of Red Hat > > > > > > > http://bill.burkecentral.com > > > > > > > _______________________________________________ > > > > > > > keycloak-dev mailing list > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > _______________________________________________ > > > > > > > keycloak-dev mailing list > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > _______________________________________________ > > > > > > > keycloak-dev mailing list > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > _______________________________________________ > > > > > > keycloak-dev mailing list > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, 5 December, 2014 1:45:24 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, December 5, 2014 10:22:10 AM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > Looks good. I reckon we can combine the two pages. What about if the 'Add > provider' drop-down is: > > OpenID > SAML > ------ > Google > GitHub > Facebook > Twitter > > Let's drop social on/off and instead have a enable/disable button on each > provider. Sure. > > Also, would be nice if users could set a name or alias for a provider > instance. This would make the callback url easier to use (instead of > callback/<UUID> it's callback/<alias>). The user federation providers have > this. One of my first tries was using an alias, just like that. But I preferred using the UUID and make the configuration more easier. Beside that, the callback url is just a copy and paste, so I think an alias would not bring so much usability, but add one more step when configuring providers. However, if this is an usability requirement for KC I can change that. > > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Friday, 5 December, 2014 1:08:53 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > In one of our last discussions, you suggested to leave Social as it is. > > Although IMO I think we can have a single place to manage both social and > > user-defined identity providers. Social ones are just OOTB and > > pre-configured identity providers now. > > > > That said, today I'm using separated tabs for social and user-defined. > > Please, take a look at [1] for more details on how the UI looks like. > > > > I've changed social UI a bit in order to provide a specific page for > > create/update. I've also added a "Show Secret" link to display the > > client_secret in clear text if user wants to. > > > > Beside the enable/disable button, I think another good thing to do is > > specify > > a default role(s) for each provider. That can be useful if applications > > want > > to perform any kind of authorization based on the identity provider or > > authentication method used to authenticate an user (eg.: useful for > > adaptative or multi-level access control). We can also use the "amr" > > claim > > in the ID Token, which seems KC is not considering at all. The latter is > > an > > important thing to think of, regardless this broker work I'm doing. > > > > [1] > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sha... > > > > ----- Original Message ----- > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Friday, December 5, 2014 6:15:15 AM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > Having a separate enable/disable for each provider would be good. If > > you're > > leaving the social tab as is and adding a separate tab for configuring > > brokered idp's then we should leave the social enable/disable button, > > otherwise it depends how it'll look like in the end. > > > > ----- Original Message ----- > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Friday, 5 December, 2014 2:29:37 AM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > Hi, > > > > > > Social has a button to enable/disable it. I'm wondering what to do > > > with > > > the brokered identity providers. Shall we add a similar flag for > > > that > > > ? > > > > > > I was also wondering if the best would be a flag in a per provider > > > basis. > > > So we can disable/enable a specific provider (social or brokered), > > > instead of doing that for all. > > > > > > Regards. > > > Pedro Igor > > > > > > ----- Original Message ----- > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Tuesday, December 2, 2014 10:42:11 AM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > ----- Original Message ----- > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > I'll go for it then. Will remove the icon url from the model and > > > > > leave > > > > > that > > > > > for users if they want to provide icons for their identity > > > > > providers. > > > > > > > > > > My point is that icons can be usually served by the same > > > > > server/application > > > > > or proxy, so download images are not such a big deal. Also, the > > > > > icon > > > > > url > > > > > is > > > > > part of the freemarker model and people can do what ever they want > > > > > with > > > > > it. > > > > > What I think will also help in your future plans. > > > > > > > > I'm not following. Are you saying that if a named image > > > > 'my-provider.png' > > > > is > > > > loaded from a theme, then you can override it in another theme? > > > > > > > > If so, that's basically the same as having a css class 'my-provider' > > > > in > > > > a > > > > theme. With the exception that with an image you end up with having > > > > to > > > > require a image per provider per theme per language, which could be a > > > > lot > > > > of > > > > images for a single provider. Also, buttons for accessibility should > > > > be > > > > defined with text and css, not images that can't be interpreted. You > > > > also > > > > still need to modify the theme, so I don't see any benefits. > > > > > > You are right. Having a icon url per provider does not makes sense if > > > there > > > are requirements to change images accordingly to a theme or language. > > > CSS > > > makes life easier. > > > > > > Will remove that property from the model. > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > Users can now specify a Icon Url to be rendered on the login page > > > > > > when > > > > > > social > > > > > > or any other identity provider is configured. So we just load the > > > > > > image > > > > > > the > > > > > > url entered by the user. > > > > > > > > > > > > Are you saying that users should change the theme or customize > > > > > > css > > > > > > if > > > > > > they > > > > > > only want to change an icon for a provider ? > > > > > > > > > > Yes, there's many issues with having a icon url: > > > > > > > > > > * Won't work for internationalization - we don't have this now, but > > > > > we > > > > > will > > > > > * Image is not a good button - CSS is much better > > > > > * Doesn't support themes - we allow users to switch l&f by > > > > > switching > > > > > themes, > > > > > but that won't work for a icon url. In the future we may also > > > > > support > > > > > multiple themes per-realm, for example to depending on the devices > > > > > (one > > > > > theme for mobiles, one for desktops, etc) > > > > > * Requires the URL to be hosted somewhere - why require a separate > > > > > call > > > > > to > > > > > download an image (to a separate server maybe) if it can simply be > > > > > defined > > > > > in a single CSS file? > > > > > > > > > > Rather than add additional places to define look and feel > > > > > components > > > > > we > > > > > should in the future make it easier to add/customize themes. > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > All look and feel related things including images and stylesheets > > > > > > should > > > > > > be > > > > > > part of themes. This is to allow customizing them in the theme. > > > > > > Also, > > > > > > an > > > > > > image is not the correct way to render a button, it should be > > > > > > defined > > > > > > in > > > > > > CSS. > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > You shouldn't have icon images for social providers. They > > > > > > > should > > > > > > > be > > > > > > > specified > > > > > > > as part of the theme in CSS as is now. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > Authentication > > > > > > > > Broker > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Anyone know where I can get the icons images for social > > > > > > > > providers > > > > > > > > ? > > > > > > > > It > > > > > > > > seems zocial defines them encoded in some way in CSS. I > > > > > > > > need > > > > > > > > that > > > > > > > > to > > > > > > > > provide default images if user does not specify their > > > > > > > > own. > > > > > > > > > > > > > > > > Or is still possible to use zocial ones ? > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > Authentication > > > > > > > > Broker > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > I've done some initial work covering both persistence and > > > > > > > > brokering. > > > > > > > > No > > > > > > > > UI, yet. I'm focused on the model, rest api and brokering > > > > > > > > functionality > > > > > > > > for now. > > > > > > > > > > > > > > > > What I have is enough to decide if we are aligned about > > > > > > > > this > > > > > > > > functionality. So you can understand how the model (and > > > > > > > > persistence), > > > > > > > > rest api and brokering functionality looks like. Can we > > > > > > > > schedule > > > > > > > > a > > > > > > > > meeting ? > > > > > > > > > > > > > > > > Btw, my branch is here [1]. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > > > > > > > > > > > Regards. > > > > > > > > Pedro Igor > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > To: keycloak-dev(a)lists.jboss.org > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > Authentication > > > > > > > > Broker > > > > > > > > > > > > > > > > Currently adapters can only make authz decisions > > > > > > > > (@RolesAllowed) > > > > > > > > based > > > > > > > > on either realm roles or the roles of one specific > > > > > > > > application. > > > > > > > > This > > > > > > > > is > > > > > > > > related to 1) too. > > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: > > > > > > > > > 1) Sounds like something definitely worth aiming for. > > > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > > > > > > > > >> I just wanted to quickly list the additional work we > > > > > > > > >> discussed > > > > > > > > >> so > > > > > > > > >> everyone > > > > > > > > >> can think about it (in no particular order): > > > > > > > > >> > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an > > > > > > > > >> external > > > > > > > > >> token > > > > > > > > >> to > > > > > > > > >> a KC token? For example an external token with attribute > > > > > > > > >> 'group' > > > > > > > > >> that > > > > > > > > >> contains 'sales' and 'manager' could be mapped to > > > > > > > > >> 'manager' > > > > > > > > >> role > > > > > > > > >> for > > > > > > > > >> 'sales app in a KC token. Could we use Drools? This could > > > > > > > > >> also > > > > > > > > >> be > > > > > > > > >> used > > > > > > > > >> in > > > > > > > > >> user federation to allow more complex mapping of > > > > > > > > >> roles/groups > > > > > > > > >> than > > > > > > > > >> a > > > > > > > > >> simple 1-1 > > > > > > > > >> 2) Retrieving tokens - if an application wants to retrieve > > > > > > > > >> the > > > > > > > > >> external > > > > > > > > >> token (for example to view Facebook friends if user logged > > > > > > > > >> in > > > > > > > > >> with > > > > > > > > >> Facebook) > > > > > > > > >> 3) Configure scope - currently for social we only request > > > > > > > > >> a > > > > > > > > >> very > > > > > > > > >> limited > > > > > > > > >> scope (basic profile and email), to for example view > > > > > > > > >> Facebook > > > > > > > > >> friends > > > > > > > > >> we'd need to ask for that as well > > > > > > > > >> 4) Selecting provider - currently in social (and for first > > > > > > > > >> pass > > > > > > > > >> of > > > > > > > > >> brokering) we have an icon user has to select, but can we > > > > > > > > >> select > > > > > > > > >> the > > > > > > > > >> provider in a different way (for example ask user for > > > > > > > > >> email, > > > > > > > > >> and > > > > > > > > >> select > > > > > > > > >> based on email domain) > > > > > > > > >> 5) Gateway - don't create a KC token, but just forward the > > > > > > > > >> external > > > > > > > > >> token > > > > > > > > >> > > > > > > > > >> IMO 1) is a killer feature, as it would allow companies to > > > > > > > > >> add > > > > > > > > >> external > > > > > > > > >> users without having to modify their applications. Issue > > > > > > > > >> with > > > > > > > > >> 5) > > > > > > > > >> is > > > > > > > > >> that > > > > > > > > >> applications need to understand more than one token, which > > > > > > > > >> would > > > > > > > > >> require > > > > > > > > >> rewriting applications. > > > > > > > > >> > > > > > > > > >> This work is also somewhat related to other authentication > > > > > > > > >> mechanisms > > > > > > > > >> (for > > > > > > > > >> example Kerberos ticket, LDAP and passwordless). > > > > > > > > >> > > > > > > > > >> ----- Original Message ----- > > > > > > > > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > >>> Authentication > > > > > > > > >>> Broker > > > > > > > > >>> > > > > > > > > >>> ----- Original Message ----- > > > > > > > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > >>>> Authentication > > > > > > > > >>>> Broker > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > > > > > > > > >>>>> Hi, > > > > > > > > >>>>> > > > > > > > > >>>>> Would like to start a discussion about how to > > > > > > > > >>>>> enable > > > > > > > > >>>>> KC > > > > > > > > >>>>> as > > > > > > > > >>>>> an > > > > > > > > >>>>> Authentication Broker in order to supported > > > > > > > > >>>>> Chained > > > > > > > > >>>>> Federation > > > > > > > > >>>>> and > > > > > > > > >>>>> also Identity Federation. First of all, some > > > > > > > > >>>>> background > > > > > > > > >>>>> about > > > > > > > > >>>>> what > > > > > > > > >>>>> this is all about. > > > > > > > > >>>>> > > > > > > > > >>>>> Currently KeyCloak provides two basic types of > > > > > > > > >>>>> authentication > > > > > > > > >>>>> (correct > > > > > > > > >>>>> me if I'm wrong, please): > > > > > > > > >>>>> > > > > > > > > >>>>> 1) Local authentication (based on some > > > > > > > > >>>>> credential > > > > > > > > >>>>> type > > > > > > > > >>>>> enabled > > > > > > > > >>>>> to > > > > > > > > >>>>> a realm) > > > > > > > > >>>>> 2) Social authentication > > > > > > > > >>>>> > > > > > > > > >>>>> Local authentication is about authenticating the > > > > > > > > >>>>> user > > > > > > > > >>>>> locally > > > > > > > > >>>>> using > > > > > > > > >>>>> KC's own identity store. Nothing special here. > > > > > > > > >>>>> And > > > > > > > > >>>>> Social > > > > > > > > >>>>> Authentication which allows users to choose the > > > > > > > > >>>>> Social > > > > > > > > >>>>> IdP > > > > > > > > >>>>> they > > > > > > > > >>>>> want > > > > > > > > >>>>> to authenticate with. In this case, the IdP is > > > > > > > > >>>>> always > > > > > > > > >>>>> one > > > > > > > > >>>>> of > > > > > > > > >>>>> the > > > > > > > > >>>>> built-in social providers supported by KC such > > > > > > > > >>>>> as > > > > > > > > >>>>> Facebook, > > > > > > > > >>>>> Google, > > > > > > > > >>>>> Twitter, Github and so forth. > > > > > > > > >>>>> > > > > > > > > >>>>> When doing social, the user is automatically > > > > > > > > >>>>> provisioned > > > > > > > > >>>>> in > > > > > > > > >>>>> KC > > > > > > > > >>>>> identity store after a successful > > > > > > > > >>>>> authentication. > > > > > > > > >>>>> The > > > > > > > > >>>>> user > > > > > > > > >>>>> does > > > > > > > > >>>>> not > > > > > > > > >>>>> need to fill a registration form and can access > > > > > > > > >>>>> the > > > > > > > > >>>>> application > > > > > > > > >>>>> very > > > > > > > > >>>>> quickly. During the provisioning some basic > > > > > > > > >>>>> information > > > > > > > > >>>>> is > > > > > > > > >>>>> retrieved > > > > > > > > >>>>> from the social provider such as email, > > > > > > > > >>>>> firstname > > > > > > > > >>>>> and > > > > > > > > >>>>> so > > > > > > > > >>>>> forth. > > > > > > > > >>>>> These > > > > > > > > >>>>> are very basic information, any other > > > > > > > > >>>>> information > > > > > > > > >>>>> such > > > > > > > > >>>>> as > > > > > > > > >>>>> those > > > > > > > > >>>>> related with authorization policies - eg.: roles > > > > > > > > >>>>> and > > > > > > > > >>>>> groups > > > > > > > > >>>>> - > > > > > > > > >>>>> must > > > > > > > > >>>>> be > > > > > > > > >>>>> defined later via KC's admin console. > > > > > > > > >>>>> > > > > > > > > >>>>> Another important characteristic of social > > > > > > > > >>>>> authentication > > > > > > > > >>>>> is > > > > > > > > >>>>> that > > > > > > > > >>>>> the > > > > > > > > >>>>> application receives a KC token and not the > > > > > > > > >>>>> token > > > > > > > > >>>>> that > > > > > > > > >>>>> was > > > > > > > > >>>>> issued by > > > > > > > > >>>>> the social IdP during the authentication > > > > > > > > >>>>> process. > > > > > > > > >>>>> If > > > > > > > > >>>>> the > > > > > > > > >>>>> application > > > > > > > > >>>>> wants to consume resources from the resource > > > > > > > > >>>>> provider > > > > > > > > >>>>> he > > > > > > > > >>>>> was > > > > > > > > >>>>> authenticated it must obtain the access > > > > > > > > >>>>> token(again) > > > > > > > > >>>>> by > > > > > > > > >>>>> itself > > > > > > > > >>>>> prior > > > > > > > > >>>>> to invoke the resource provider API. Assuming > > > > > > > > >>>>> all > > > > > > > > >>>>> those > > > > > > > > >>>>> social > > > > > > > > >>>>> providers are based on oAuth 1.0 or 2.0. > > > > > > > > >>>>> > > > > > > > > >>>>> That said, the Authentication Broker > > > > > > > > >>>>> functionality > > > > > > > > >>>>> aims > > > > > > > > >>>>> to > > > > > > > > >>>>> cover > > > > > > > > >>>>> the > > > > > > > > >>>>> same use cases but with a lot of more > > > > > > > > >>>>> flexibility > > > > > > > > >>>>> on > > > > > > > > >>>>> how > > > > > > > > >>>>> you > > > > > > > > >>>>> setup > > > > > > > > >>>>> identity providers(not only social ones) and the > > > > > > > > >>>>> different > > > > > > > > >>>>> federation > > > > > > > > >>>>> protocols they may support such as SAML, OpenID, > > > > > > > > >>>>> oAuth > > > > > > > > >>>>> and > > > > > > > > >>>>> so > > > > > > > > >>>>> forth. > > > > > > > > >>>>> This is useful when an enterprise is providing > > > > > > > > >>>>> services > > > > > > > > >>>>> to > > > > > > > > >>>>> different > > > > > > > > >>>>> customers(IdP) and does not want to manage many > > > > > > > > >>>>> to > > > > > > > > >>>>> many > > > > > > > > >>>>> relationships. When using a broker, the > > > > > > > > >>>>> authentication > > > > > > > > >>>>> steps > > > > > > > > >>>>> are > > > > > > > > >>>>> pretty much the same when you are using social > > > > > > > > >>>>> authentication, > > > > > > > > >>>>> with > > > > > > > > >>>>> important differences on how you support > > > > > > > > >>>>> different > > > > > > > > >>>>> identity > > > > > > > > >>>>> providers, different federation protocols, how > > > > > > > > >>>>> users > > > > > > > > >>>>> are > > > > > > > > >>>>> provisioned > > > > > > > > >>>>> and how claims and attributes are resolved. > > > > > > > > >>>>> > > > > > > > > >>>>> The brokering functionality can be done in two > > > > > > > > >>>>> ways > > > > > > > > >>>>> depending > > > > > > > > >>>>> if > > > > > > > > >>>>> the > > > > > > > > >>>>> broker service is acting as a gateway or not. > > > > > > > > >>>>> When > > > > > > > > >>>>> acting > > > > > > > > >>>>> as > > > > > > > > >>>>> a > > > > > > > > >>>>> gateway, the broker will respond to the > > > > > > > > >>>>> application > > > > > > > > >>>>> the > > > > > > > > >>>>> same > > > > > > > > >>>>> token > > > > > > > > >>>>> issued by the trusted identity provider. For > > > > > > > > >>>>> instance, > > > > > > > > >>>>> if > > > > > > > > >>>>> the > > > > > > > > >>>>> user > > > > > > > > >>>>> selects a SAML IdP to authenticate with, the > > > > > > > > >>>>> application > > > > > > > > >>>>> will > > > > > > > > >>>>> receive > > > > > > > > >>>>> a SAML Response. In this case, the application > > > > > > > > >>>>> must > > > > > > > > >>>>> also > > > > > > > > >>>>> be > > > > > > > > >>>>> prepared > > > > > > > > >>>>> to handle a specific federation protocol. > > > > > > > > >>>>> > > > > > > > > >>>>> However, the broker service can also be used to > > > > > > > > >>>>> completely > > > > > > > > >>>>> abstract > > > > > > > > >>>>> from the application the protocol used to > > > > > > > > >>>>> authenticate > > > > > > > > >>>>> an > > > > > > > > >>>>> user. > > > > > > > > >>>>> In > > > > > > > > >>>>> this case, the application will just receive an > > > > > > > > >>>>> ordinary > > > > > > > > >>>>> KC > > > > > > > > >>>>> token > > > > > > > > >>>>> after a successful authentication. > > > > > > > > >>>>> > > > > > > > > >>>>> In both cases, the broker acts as an > > > > > > > > >>>>> intermediary > > > > > > > > >>>>> where > > > > > > > > >>>>> specific > > > > > > > > >>>>> security policies can be applied when users try > > > > > > > > >>>>> to > > > > > > > > >>>>> authenticate > > > > > > > > >>>>> themselves against a 3rd party IdP. That brings > > > > > > > > >>>>> a > > > > > > > > >>>>> lot > > > > > > > > >>>>> of > > > > > > > > >>>>> value > > > > > > > > >>>>> when > > > > > > > > >>>>> you think about auditing, authorization and how > > > > > > > > >>>>> users > > > > > > > > >>>>> are > > > > > > > > >>>>> provisioned > > > > > > > > >>>>> when federation of identities is needed. This > > > > > > > > >>>>> also > > > > > > > > >>>>> allows > > > > > > > > >>>>> existing > > > > > > > > >>>>> security infrastructures (eg.: SAML-based > > > > > > > > >>>>> infrastructures) > > > > > > > > >>>>> to > > > > > > > > >>>>> benefit > > > > > > > > >>>>> from KC's support for cloud, rest and mobile use > > > > > > > > >>>>> cases. > > > > > > > > >>>>> > > > > > > > > >>>>> I think this is enough to start a discussion. > > > > > > > > >>>>> I've > > > > > > > > >>>>> an > > > > > > > > >>>>> initial > > > > > > > > >>>>> discussion with Stian about all that and we > > > > > > > > >>>>> agreed > > > > > > > > >>>>> that > > > > > > > > >>>>> abstract > > > > > > > > >>>>> the > > > > > > > > >>>>> protocol from applications should be > > > > > > > > >>>>> prioritized. > > > > > > > > >>>>> The > > > > > > > > >>>>> main > > > > > > > > >>>>> reason is > > > > > > > > >>>>> that it makes life easier for applications so > > > > > > > > >>>>> they > > > > > > > > >>>>> only > > > > > > > > >>>>> need > > > > > > > > >>>>> to > > > > > > > > >>>>> know > > > > > > > > >>>>> about KC tokens and nothing else. However that > > > > > > > > >>>>> brings > > > > > > > > >>>>> some > > > > > > > > >>>>> new > > > > > > > > >>>>> requirements around user provisioning and > > > > > > > > >>>>> claim/attribute > > > > > > > > >>>>> resolution > > > > > > > > >>>>> or mapping. But that would be another thread. > > > > > > > > >>>>> > > > > > > > > >>>> > > > > > > > > >>>> Can you elaborate on "abstract the protocol from > > > > > > > > >>>> applications"? > > > > > > > > >>>> Not > > > > > > > > >>>> sure what you mean by that. IDP federation should be > > > > > > > > >>>> configured > > > > > > > > >>>> at > > > > > > > > >>>> the > > > > > > > > >>>> realm level and really has nothing to do with > > > > > > > > >>>> applications. > > > > > > > > >>>> > > > > > > > > >>>> I'm really happy that somebody is doing this. We're > > > > > > > > >>>> getting > > > > > > > > >>>> a > > > > > > > > >>>> real > > > > > > > > >>>> impressive feature set! > > > > > > > > >>> > > > > > > > > >>> Sure. What I meant was that the application only knows > > > > > > > > >>> about > > > > > > > > >>> KC > > > > > > > > >>> tokens > > > > > > > > >>> nothing else. It will always receive a KC token > > > > > > > > >>> regardless > > > > > > > > >>> the > > > > > > > > >>> protocol > > > > > > > > >>> used > > > > > > > > >>> to authenticate the user against a 3rd party IdP (saml, > > > > > > > > >>> oidc, > > > > > > > > >>> whatever). > > > > > > > > >>> The > > > > > > > > >>> example I gave was about an user trying to authenticate > > > > > > > > >>> against > > > > > > > > >>> a > > > > > > > > >>> SAML > > > > > > > > >>> IdP. > > > > > > > > >>> In this case, after a successful authentication on the > > > > > > > > >>> IdP, > > > > > > > > >>> the > > > > > > > > >>> IdP > > > > > > > > >>> will > > > > > > > > >>> issue a token to KC. Then KC will validate the token, > > > > > > > > >>> perform > > > > > > > > >>> trust > > > > > > > > >>> and > > > > > > > > >>> security checks, do user provisioning and attribute/claim > > > > > > > > >>> resolution > > > > > > > > >>> to > > > > > > > > >>> finally issue a KC token and redirect the user to the > > > > > > > > >>> application. > > > > > > > > >>> If > > > > > > > > >>> the > > > > > > > > >>> app is configured to use openid in KC then it will > > > > > > > > >>> receive > > > > > > > > >>> a > > > > > > > > >>> openid > > > > > > > > >>> token > > > > > > > > >>> from KC, not saml ... > > > > > > > > >>> > > > > > > > > >>> The other scenario is pretty much the same. The > > > > > > > > >>> difference > > > > > > > > >>> is > > > > > > > > >>> that > > > > > > > > >>> KC > > > > > > > > >>> will > > > > > > > > >>> not issue its own token but just replay the token issued > > > > > > > > >>> by > > > > > > > > >>> the > > > > > > > > >>> 3rd > > > > > > > > >>> party > > > > > > > > >>> IdP to the service provider. > > > > > > > > >>> > > > > > > > > >>> I agree that this config goes at the realm level. For > > > > > > > > >>> instance, > > > > > > > > >>> to > > > > > > > > >>> create > > > > > > > > >>> and > > > > > > > > >>> enable providers for being used. However, I think we > > > > > > > > >>> would > > > > > > > > >>> need > > > > > > > > >>> some > > > > > > > > >>> specific configuration for applications as well. > > > > > > > > >>> Specially > > > > > > > > >>> when > > > > > > > > >>> defining > > > > > > > > >>> default roles, mapping attributes. Another example of > > > > > > > > >>> application > > > > > > > > >>> config > > > > > > > > >>> is > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define > > > > > > > > >>> scopes > > > > > > > > >>> per-application. > > > > > > > > >>> > > > > > > > > >>>> > > > > > > > > >>>> -- > > > > > > > > >>>> Bill Burke > > > > > > > > >>>> JBoss, a division of Red Hat > > > > > > > > >>>> http://bill.burkecentral.com > > > > > > > > >>>> _______________________________________________ > > > > > > > > >>>> keycloak-dev mailing list > > > > > > > > >>>> keycloak-dev(a)lists.jboss.org > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > >>>> > > > > > > > > >>> _______________________________________________ > > > > > > > > >>> keycloak-dev mailing list > > > > > > > > >>> keycloak-dev(a)lists.jboss.org > > > > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > >>> > > > > > > > > >> _______________________________________________ > > > > > > > > >> keycloak-dev mailing list > > > > > > > > >> keycloak-dev(a)lists.jboss.org > > > > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Bill Burke > > > > > > > > JBoss, a division of Red Hat > > > > > > > > http://bill.burkecentral.com > > > > > > > > _______________________________________________ > > > > > > > > keycloak-dev mailing list > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > keycloak-dev mailing list > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > keycloak-dev mailing list > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > _______________________________________________ > > > > > > > keycloak-dev mailing list > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > >

Having a separate enable/disable for each provider would be good. If you're leaving the social tab as is and adding a separate tab for configuring brokered idp's then we should leave the social enable/disable button, otherwise it depends how it'll look like in the end. ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, 5 December, 2014 2:29:37 AM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > Hi, > > Social has a button to enable/disable it. I'm wondering what to do with > the brokered identity providers. Shall we add a similar flag for that ? > > I was also wondering if the best would be a flag in a per provider basis. > So we can disable/enable a specific provider (social or brokered), > instead of doing that for all. > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Tuesday, December 2, 2014 10:42:11 AM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > ----- Original Message ----- >> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Tuesday, December 2, 2014 10:23:24 AM >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >> >> >> >> ----- Original Message ----- >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Tuesday, 2 December, 2014 1:13:08 PM >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>> >>> I'll go for it then. Will remove the icon url from the model and leave >>> that >>> for users if they want to provide icons for their identity providers. >>> >>> My point is that icons can be usually served by the same >>> server/application >>> or proxy, so download images are not such a big deal. Also, the icon url >>> is >>> part of the freemarker model and people can do what ever they want with >>> it. >>> What I think will also help in your future plans. >> >> I'm not following. Are you saying that if a named image 'my-provider.png' >> is >> loaded from a theme, then you can override it in another theme? >> >> If so, that's basically the same as having a css class 'my-provider' in a >> theme. With the exception that with an image you end up with having to >> require a image per provider per theme per language, which could be a lot >> of >> images for a single provider. Also, buttons for accessibility should be >> defined with text and css, not images that can't be interpreted. You also >> still need to modify the theme, so I don't see any benefits. > > You are right. Having a icon url per provider does not makes sense if there > are requirements to change images accordingly to a theme or language. CSS > makes life easier. > > Will remove that property from the model. > >> >>> >>> ----- Original Message ----- >>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Tuesday, December 2, 2014 10:04:33 AM >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>> >>> >>> ----- Original Message ----- >>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)lists.jboss.org >>>> Sent: Tuesday, 2 December, 2014 12:55:21 PM >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>> Broker >>>> >>>> Users can now specify a Icon Url to be rendered on the login page when >>>> social >>>> or any other identity provider is configured. So we just load the image >>>> the >>>> url entered by the user. >>>> >>>> Are you saying that users should change the theme or customize css if >>>> they >>>> only want to change an icon for a provider ? >>> >>> Yes, there's many issues with having a icon url: >>> >>> * Won't work for internationalization - we don't have this now, but we >>> will >>> * Image is not a good button - CSS is much better >>> * Doesn't support themes - we allow users to switch l&f by switching >>> themes, >>> but that won't work for a icon url. In the future we may also support >>> multiple themes per-realm, for example to depending on the devices (one >>> theme for mobiles, one for desktops, etc) >>> * Requires the URL to be hosted somewhere - why require a separate call >>> to >>> download an image (to a separate server maybe) if it can simply be >>> defined >>> in a single CSS file? >>> >>> Rather than add additional places to define look and feel components we >>> should in the future make it easier to add/customize themes. >>> >>>> >>>> ----- Original Message ----- >>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)lists.jboss.org >>>> Sent: Tuesday, December 2, 2014 9:42:15 AM >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>> Broker >>>> >>>> All look and feel related things including images and stylesheets >>>> should >>>> be >>>> part of themes. This is to allow customizing them in the theme. Also, >>>> an >>>> image is not the correct way to render a button, it should be defined >>>> in >>>> CSS. >>>> >>>> ----- Original Message ----- >>>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>> Sent: Tuesday, 2 December, 2014 12:34:45 PM >>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>> Broker >>>>> >>>>> You shouldn't have icon images for social providers. They should be >>>>> specified >>>>> as part of the theme in CSS as is now. >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>>> Sent: Tuesday, 2 December, 2014 12:22:21 PM >>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>>> Broker >>>>>> >>>>>> Hi, >>>>>> >>>>>> Anyone know where I can get the icons images for social >>>>>> providers >>>>>> ? >>>>>> It >>>>>> seems zocial defines them encoded in some way in CSS. I need >>>>>> that >>>>>> to >>>>>> provide default images if user does not specify their own. >>>>>> >>>>>> Or is still possible to use zocial ones ? >>>>>> >>>>>> Regards. >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>>> Sent: Thursday, November 27, 2014 9:01:38 PM >>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>>> Broker >>>>>> >>>>>> Hi guys, >>>>>> >>>>>> I've done some initial work covering both persistence and >>>>>> brokering. >>>>>> No >>>>>> UI, yet. I'm focused on the model, rest api and brokering >>>>>> functionality >>>>>> for now. >>>>>> >>>>>> What I have is enough to decide if we are aligned about this >>>>>> functionality. So you can understand how the model (and >>>>>> persistence), >>>>>> rest api and brokering functionality looks like. Can we schedule >>>>>> a >>>>>> meeting ? >>>>>> >>>>>> Btw, my branch is here [1]. >>>>>> >>>>>> [1] >>>>>> https://github.com/pedroigor/keycloak/tree/authentication-broker2 >>>>>> >>>>>> Regards. >>>>>> Pedro Igor >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>> To: keycloak-dev(a)lists.jboss.org >>>>>> Sent: Thursday, November 20, 2014 2:48:49 PM >>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>>> Broker >>>>>> >>>>>> Currently adapters can only make authz decisions (@RolesAllowed) >>>>>> based >>>>>> on either realm roles or the roles of one specific application. >>>>>> This >>>>>> is >>>>>> related to 1) too. >>>>>> >>>>>> On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: >>>>>>> 1) Sounds like something definitely worth aiming for. >>>>>>> >>>>>>> On 11/20/2014 09:55 AM, Stian Thorgersen wrote: >>>>>>>> I just wanted to quickly list the additional work we discussed >>>>>>>> so >>>>>>>> everyone >>>>>>>> can think about it (in no particular order): >>>>>>>> >>>>>>>> 1) Mapping of tokens - how do we deal with mapping of an >>>>>>>> external >>>>>>>> token >>>>>>>> to >>>>>>>> a KC token? For example an external token with attribute 'group' >>>>>>>> that >>>>>>>> contains 'sales' and 'manager' could be mapped to 'manager' role >>>>>>>> for >>>>>>>> 'sales app in a KC token. Could we use Drools? This could also >>>>>>>> be >>>>>>>> used >>>>>>>> in >>>>>>>> user federation to allow more complex mapping of roles/groups >>>>>>>> than >>>>>>>> a >>>>>>>> simple 1-1 >>>>>>>> 2) Retrieving tokens - if an application wants to retrieve the >>>>>>>> external >>>>>>>> token (for example to view Facebook friends if user logged in >>>>>>>> with >>>>>>>> Facebook) >>>>>>>> 3) Configure scope - currently for social we only request a very >>>>>>>> limited >>>>>>>> scope (basic profile and email), to for example view Facebook >>>>>>>> friends >>>>>>>> we'd need to ask for that as well >>>>>>>> 4) Selecting provider - currently in social (and for first pass >>>>>>>> of >>>>>>>> brokering) we have an icon user has to select, but can we select >>>>>>>> the >>>>>>>> provider in a different way (for example ask user for email, and >>>>>>>> select >>>>>>>> based on email domain) >>>>>>>> 5) Gateway - don't create a KC token, but just forward the >>>>>>>> external >>>>>>>> token >>>>>>>> >>>>>>>> IMO 1) is a killer feature, as it would allow companies to add >>>>>>>> external >>>>>>>> users without having to modify their applications. Issue with 5) >>>>>>>> is >>>>>>>> that >>>>>>>> applications need to understand more than one token, which would >>>>>>>> require >>>>>>>> rewriting applications. >>>>>>>> >>>>>>>> This work is also somewhat related to other authentication >>>>>>>> mechanisms >>>>>>>> (for >>>>>>>> example Kerberos ticket, LDAP and passwordless). >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>>>>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>>>>>> Sent: Wednesday, 19 November, 2014 8:27:58 PM >>>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and >>>>>>>>> Authentication >>>>>>>>> Broker >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>>>>>> To: keycloak-dev(a)lists.jboss.org >>>>>>>>>> Sent: Wednesday, November 19, 2014 4:39:52 PM >>>>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and >>>>>>>>>> Authentication >>>>>>>>>> Broker >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Would like to start a discussion about how to enable >>>>>>>>>>> KC >>>>>>>>>>> as >>>>>>>>>>> an >>>>>>>>>>> Authentication Broker in order to supported Chained >>>>>>>>>>> Federation >>>>>>>>>>> and >>>>>>>>>>> also Identity Federation. First of all, some >>>>>>>>>>> background >>>>>>>>>>> about >>>>>>>>>>> what >>>>>>>>>>> this is all about. >>>>>>>>>>> >>>>>>>>>>> Currently KeyCloak provides two basic types of >>>>>>>>>>> authentication >>>>>>>>>>> (correct >>>>>>>>>>> me if I'm wrong, please): >>>>>>>>>>> >>>>>>>>>>> 1) Local authentication (based on some credential >>>>>>>>>>> type >>>>>>>>>>> enabled >>>>>>>>>>> to >>>>>>>>>>> a realm) >>>>>>>>>>> 2) Social authentication >>>>>>>>>>> >>>>>>>>>>> Local authentication is about authenticating the user >>>>>>>>>>> locally >>>>>>>>>>> using >>>>>>>>>>> KC's own identity store. Nothing special here. And >>>>>>>>>>> Social >>>>>>>>>>> Authentication which allows users to choose the Social >>>>>>>>>>> IdP >>>>>>>>>>> they >>>>>>>>>>> want >>>>>>>>>>> to authenticate with. In this case, the IdP is always >>>>>>>>>>> one >>>>>>>>>>> of >>>>>>>>>>> the >>>>>>>>>>> built-in social providers supported by KC such as >>>>>>>>>>> Facebook, >>>>>>>>>>> Google, >>>>>>>>>>> Twitter, Github and so forth. >>>>>>>>>>> >>>>>>>>>>> When doing social, the user is automatically >>>>>>>>>>> provisioned >>>>>>>>>>> in >>>>>>>>>>> KC >>>>>>>>>>> identity store after a successful authentication. The >>>>>>>>>>> user >>>>>>>>>>> does >>>>>>>>>>> not >>>>>>>>>>> need to fill a registration form and can access the >>>>>>>>>>> application >>>>>>>>>>> very >>>>>>>>>>> quickly. During the provisioning some basic >>>>>>>>>>> information >>>>>>>>>>> is >>>>>>>>>>> retrieved >>>>>>>>>>> from the social provider such as email, firstname and >>>>>>>>>>> so >>>>>>>>>>> forth. >>>>>>>>>>> These >>>>>>>>>>> are very basic information, any other information such >>>>>>>>>>> as >>>>>>>>>>> those >>>>>>>>>>> related with authorization policies - eg.: roles and >>>>>>>>>>> groups >>>>>>>>>>> - >>>>>>>>>>> must >>>>>>>>>>> be >>>>>>>>>>> defined later via KC's admin console. >>>>>>>>>>> >>>>>>>>>>> Another important characteristic of social >>>>>>>>>>> authentication >>>>>>>>>>> is >>>>>>>>>>> that >>>>>>>>>>> the >>>>>>>>>>> application receives a KC token and not the token that >>>>>>>>>>> was >>>>>>>>>>> issued by >>>>>>>>>>> the social IdP during the authentication process. If >>>>>>>>>>> the >>>>>>>>>>> application >>>>>>>>>>> wants to consume resources from the resource provider >>>>>>>>>>> he >>>>>>>>>>> was >>>>>>>>>>> authenticated it must obtain the access token(again) >>>>>>>>>>> by >>>>>>>>>>> itself >>>>>>>>>>> prior >>>>>>>>>>> to invoke the resource provider API. Assuming all >>>>>>>>>>> those >>>>>>>>>>> social >>>>>>>>>>> providers are based on oAuth 1.0 or 2.0. >>>>>>>>>>> >>>>>>>>>>> That said, the Authentication Broker functionality >>>>>>>>>>> aims >>>>>>>>>>> to >>>>>>>>>>> cover >>>>>>>>>>> the >>>>>>>>>>> same use cases but with a lot of more flexibility on >>>>>>>>>>> how >>>>>>>>>>> you >>>>>>>>>>> setup >>>>>>>>>>> identity providers(not only social ones) and the >>>>>>>>>>> different >>>>>>>>>>> federation >>>>>>>>>>> protocols they may support such as SAML, OpenID, oAuth >>>>>>>>>>> and >>>>>>>>>>> so >>>>>>>>>>> forth. >>>>>>>>>>> This is useful when an enterprise is providing >>>>>>>>>>> services >>>>>>>>>>> to >>>>>>>>>>> different >>>>>>>>>>> customers(IdP) and does not want to manage many to >>>>>>>>>>> many >>>>>>>>>>> relationships. When using a broker, the authentication >>>>>>>>>>> steps >>>>>>>>>>> are >>>>>>>>>>> pretty much the same when you are using social >>>>>>>>>>> authentication, >>>>>>>>>>> with >>>>>>>>>>> important differences on how you support different >>>>>>>>>>> identity >>>>>>>>>>> providers, different federation protocols, how users >>>>>>>>>>> are >>>>>>>>>>> provisioned >>>>>>>>>>> and how claims and attributes are resolved. >>>>>>>>>>> >>>>>>>>>>> The brokering functionality can be done in two ways >>>>>>>>>>> depending >>>>>>>>>>> if >>>>>>>>>>> the >>>>>>>>>>> broker service is acting as a gateway or not. When >>>>>>>>>>> acting >>>>>>>>>>> as >>>>>>>>>>> a >>>>>>>>>>> gateway, the broker will respond to the application >>>>>>>>>>> the >>>>>>>>>>> same >>>>>>>>>>> token >>>>>>>>>>> issued by the trusted identity provider. For instance, >>>>>>>>>>> if >>>>>>>>>>> the >>>>>>>>>>> user >>>>>>>>>>> selects a SAML IdP to authenticate with, the >>>>>>>>>>> application >>>>>>>>>>> will >>>>>>>>>>> receive >>>>>>>>>>> a SAML Response. In this case, the application must >>>>>>>>>>> also >>>>>>>>>>> be >>>>>>>>>>> prepared >>>>>>>>>>> to handle a specific federation protocol. >>>>>>>>>>> >>>>>>>>>>> However, the broker service can also be used to >>>>>>>>>>> completely >>>>>>>>>>> abstract >>>>>>>>>>> from the application the protocol used to authenticate >>>>>>>>>>> an >>>>>>>>>>> user. >>>>>>>>>>> In >>>>>>>>>>> this case, the application will just receive an >>>>>>>>>>> ordinary >>>>>>>>>>> KC >>>>>>>>>>> token >>>>>>>>>>> after a successful authentication. >>>>>>>>>>> >>>>>>>>>>> In both cases, the broker acts as an intermediary >>>>>>>>>>> where >>>>>>>>>>> specific >>>>>>>>>>> security policies can be applied when users try to >>>>>>>>>>> authenticate >>>>>>>>>>> themselves against a 3rd party IdP. That brings a lot >>>>>>>>>>> of >>>>>>>>>>> value >>>>>>>>>>> when >>>>>>>>>>> you think about auditing, authorization and how users >>>>>>>>>>> are >>>>>>>>>>> provisioned >>>>>>>>>>> when federation of identities is needed. This also >>>>>>>>>>> allows >>>>>>>>>>> existing >>>>>>>>>>> security infrastructures (eg.: SAML-based >>>>>>>>>>> infrastructures) >>>>>>>>>>> to >>>>>>>>>>> benefit >>>>>>>>>>> from KC's support for cloud, rest and mobile use >>>>>>>>>>> cases. >>>>>>>>>>> >>>>>>>>>>> I think this is enough to start a discussion. I've an >>>>>>>>>>> initial >>>>>>>>>>> discussion with Stian about all that and we agreed >>>>>>>>>>> that >>>>>>>>>>> abstract >>>>>>>>>>> the >>>>>>>>>>> protocol from applications should be prioritized. The >>>>>>>>>>> main >>>>>>>>>>> reason is >>>>>>>>>>> that it makes life easier for applications so they >>>>>>>>>>> only >>>>>>>>>>> need >>>>>>>>>>> to >>>>>>>>>>> know >>>>>>>>>>> about KC tokens and nothing else. However that brings >>>>>>>>>>> some >>>>>>>>>>> new >>>>>>>>>>> requirements around user provisioning and >>>>>>>>>>> claim/attribute >>>>>>>>>>> resolution >>>>>>>>>>> or mapping. But that would be another thread. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Can you elaborate on "abstract the protocol from >>>>>>>>>> applications"? >>>>>>>>>> Not >>>>>>>>>> sure what you mean by that. IDP federation should be >>>>>>>>>> configured >>>>>>>>>> at >>>>>>>>>> the >>>>>>>>>> realm level and really has nothing to do with applications. >>>>>>>>>> >>>>>>>>>> I'm really happy that somebody is doing this. We're getting a >>>>>>>>>> real >>>>>>>>>> impressive feature set! >>>>>>>>> >>>>>>>>> Sure. What I meant was that the application only knows about KC >>>>>>>>> tokens >>>>>>>>> nothing else. It will always receive a KC token regardless the >>>>>>>>> protocol >>>>>>>>> used >>>>>>>>> to authenticate the user against a 3rd party IdP (saml, oidc, >>>>>>>>> whatever). >>>>>>>>> The >>>>>>>>> example I gave was about an user trying to authenticate against >>>>>>>>> a >>>>>>>>> SAML >>>>>>>>> IdP. >>>>>>>>> In this case, after a successful authentication on the IdP, the >>>>>>>>> IdP >>>>>>>>> will >>>>>>>>> issue a token to KC. Then KC will validate the token, perform >>>>>>>>> trust >>>>>>>>> and >>>>>>>>> security checks, do user provisioning and attribute/claim >>>>>>>>> resolution >>>>>>>>> to >>>>>>>>> finally issue a KC token and redirect the user to the >>>>>>>>> application. >>>>>>>>> If >>>>>>>>> the >>>>>>>>> app is configured to use openid in KC then it will receive a >>>>>>>>> openid >>>>>>>>> token >>>>>>>>> from KC, not saml ... >>>>>>>>> >>>>>>>>> The other scenario is pretty much the same. The difference is >>>>>>>>> that >>>>>>>>> KC >>>>>>>>> will >>>>>>>>> not issue its own token but just replay the token issued by the >>>>>>>>> 3rd >>>>>>>>> party >>>>>>>>> IdP to the service provider. >>>>>>>>> >>>>>>>>> I agree that this config goes at the realm level. For instance, >>>>>>>>> to >>>>>>>>> create >>>>>>>>> and >>>>>>>>> enable providers for being used. However, I think we would need >>>>>>>>> some >>>>>>>>> specific configuration for applications as well. Specially when >>>>>>>>> defining >>>>>>>>> default roles, mapping attributes. Another example of >>>>>>>>> application >>>>>>>>> config >>>>>>>>> is >>>>>>>>> when using a OIDC/oAuth IdP. You may want to define scopes >>>>>>>>> per-application. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Bill Burke >>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>> _______________________________________________ >>>>>>>>>> keycloak-dev mailing list >>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> keycloak-dev mailing list >>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> keycloak-dev mailing list >>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Bill Burke >>>>>> JBoss, a division of Red Hat >>>>>> http://bill.burkecentral.com >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, December 5, 2014 10:59:08 AM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker Another related thing. We've had a few people ask to be able to login to Keycloak on mobiles using the native social login mechanism. I think the best way to do that is to use the direct grant api and make it possible to call that endpoint passing a IdP id and a token instead of username and password. WDYT?

----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, 5 December, 2014 1:45:24 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > ----- Original Message ----- > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Friday, December 5, 2014 10:22:10 AM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > Looks good. I reckon we can combine the two pages. What about if the 'Add > > provider' drop-down is: > > > > OpenID > > SAML > > ------ > > Google > > GitHub > > Facebook > > Twitter > > > > Let's drop social on/off and instead have a enable/disable button on each > > provider. > > Sure. > > > > > Also, would be nice if users could set a name or alias for a provider > > instance. This would make the callback url easier to use (instead of > > callback/<UUID> it's callback/<alias>). The user federation providers > > have > > this. > > One of my first tries was using an alias, just like that. But I preferred > using the UUID and make the configuration more easier. Beside that, the > callback url is just a copy and paste, so I think an alias would not bring > so much usability, but add one more step when configuring providers. > > However, if this is an usability requirement for KC I can change that. > > > > > > > ----- Original Message ----- > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Friday, 5 December, 2014 1:08:53 PM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > In one of our last discussions, you suggested to leave Social as it is. > > > Although IMO I think we can have a single place to manage both social > > > and > > > user-defined identity providers. Social ones are just OOTB and > > > pre-configured identity providers now. > > > > > > That said, today I'm using separated tabs for social and user-defined. > > > Please, take a look at [1] for more details on how the UI looks like. > > > > > > I've changed social UI a bit in order to provide a specific page for > > > create/update. I've also added a "Show Secret" link to display the > > > client_secret in clear text if user wants to. > > > > > > Beside the enable/disable button, I think another good thing to do is > > > specify > > > a default role(s) for each provider. That can be useful if applications > > > want > > > to perform any kind of authorization based on the identity provider or > > > authentication method used to authenticate an user (eg.: useful for > > > adaptative or multi-level access control). We can also use the "amr" > > > claim > > > in the ID Token, which seems KC is not considering at all. The latter > > > is > > > an > > > important thing to think of, regardless this broker work I'm doing. > > > > > > [1] > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sha... > > > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Friday, December 5, 2014 6:15:15 AM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > Having a separate enable/disable for each provider would be good. If > > > you're > > > leaving the social tab as is and adding a separate tab for configuring > > > brokered idp's then we should leave the social enable/disable button, > > > otherwise it depends how it'll look like in the end. > > > > > > ----- Original Message ----- > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Friday, 5 December, 2014 2:29:37 AM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > Hi, > > > > > > > > Social has a button to enable/disable it. I'm wondering what to do > > > > with > > > > the brokered identity providers. Shall we add a similar flag for > > > > that > > > > ? > > > > > > > > I was also wondering if the best would be a flag in a per provider > > > > basis. > > > > So we can disable/enable a specific provider (social or brokered), > > > > instead of doing that for all. > > > > > > > > Regards. > > > > Pedro Igor > > > > > > > > ----- Original Message ----- > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > ----- Original Message ----- > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > I'll go for it then. Will remove the icon url from the model and > > > > > > leave > > > > > > that > > > > > > for users if they want to provide icons for their identity > > > > > > providers. > > > > > > > > > > > > My point is that icons can be usually served by the same > > > > > > server/application > > > > > > or proxy, so download images are not such a big deal. Also, the > > > > > > icon > > > > > > url > > > > > > is > > > > > > part of the freemarker model and people can do what ever they > > > > > > want > > > > > > with > > > > > > it. > > > > > > What I think will also help in your future plans. > > > > > > > > > > I'm not following. Are you saying that if a named image > > > > > 'my-provider.png' > > > > > is > > > > > loaded from a theme, then you can override it in another theme? > > > > > > > > > > If so, that's basically the same as having a css class > > > > > 'my-provider' > > > > > in > > > > > a > > > > > theme. With the exception that with an image you end up with having > > > > > to > > > > > require a image per provider per theme per language, which could be > > > > > a > > > > > lot > > > > > of > > > > > images for a single provider. Also, buttons for accessibility > > > > > should > > > > > be > > > > > defined with text and css, not images that can't be interpreted. > > > > > You > > > > > also > > > > > still need to modify the theme, so I don't see any benefits. > > > > > > > > You are right. Having a icon url per provider does not makes sense if > > > > there > > > > are requirements to change images accordingly to a theme or language. > > > > CSS > > > > makes life easier. > > > > > > > > Will remove that property from the model. > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > Users can now specify a Icon Url to be rendered on the login > > > > > > > page > > > > > > > when > > > > > > > social > > > > > > > or any other identity provider is configured. So we just load > > > > > > > the > > > > > > > image > > > > > > > the > > > > > > > url entered by the user. > > > > > > > > > > > > > > Are you saying that users should change the theme or customize > > > > > > > css > > > > > > > if > > > > > > > they > > > > > > > only want to change an icon for a provider ? > > > > > > > > > > > > Yes, there's many issues with having a icon url: > > > > > > > > > > > > * Won't work for internationalization - we don't have this now, > > > > > > but > > > > > > we > > > > > > will > > > > > > * Image is not a good button - CSS is much better > > > > > > * Doesn't support themes - we allow users to switch l&f by > > > > > > switching > > > > > > themes, > > > > > > but that won't work for a icon url. In the future we may also > > > > > > support > > > > > > multiple themes per-realm, for example to depending on the > > > > > > devices > > > > > > (one > > > > > > theme for mobiles, one for desktops, etc) > > > > > > * Requires the URL to be hosted somewhere - why require a > > > > > > separate > > > > > > call > > > > > > to > > > > > > download an image (to a separate server maybe) if it can simply > > > > > > be > > > > > > defined > > > > > > in a single CSS file? > > > > > > > > > > > > Rather than add additional places to define look and feel > > > > > > components > > > > > > we > > > > > > should in the future make it easier to add/customize themes. > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > All look and feel related things including images and > > > > > > > stylesheets > > > > > > > should > > > > > > > be > > > > > > > part of themes. This is to allow customizing them in the theme. > > > > > > > Also, > > > > > > > an > > > > > > > image is not the correct way to render a button, it should be > > > > > > > defined > > > > > > > in > > > > > > > CSS. > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > Authentication > > > > > > > > Broker > > > > > > > > > > > > > > > > You shouldn't have icon images for social providers. They > > > > > > > > should > > > > > > > > be > > > > > > > > specified > > > > > > > > as part of the theme in CSS as is now. > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > Authentication > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Anyone know where I can get the icons images for social > > > > > > > > > providers > > > > > > > > > ? > > > > > > > > > It > > > > > > > > > seems zocial defines them encoded in some way in CSS. I > > > > > > > > > need > > > > > > > > > that > > > > > > > > > to > > > > > > > > > provide default images if user does not specify their > > > > > > > > > own. > > > > > > > > > > > > > > > > > > Or is still possible to use zocial ones ? > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > Authentication > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > > > I've done some initial work covering both persistence > > > > > > > > > and > > > > > > > > > brokering. > > > > > > > > > No > > > > > > > > > UI, yet. I'm focused on the model, rest api and > > > > > > > > > brokering > > > > > > > > > functionality > > > > > > > > > for now. > > > > > > > > > > > > > > > > > > What I have is enough to decide if we are aligned about > > > > > > > > > this > > > > > > > > > functionality. So you can understand how the model (and > > > > > > > > > persistence), > > > > > > > > > rest api and brokering functionality looks like. Can we > > > > > > > > > schedule > > > > > > > > > a > > > > > > > > > meeting ? > > > > > > > > > > > > > > > > > > Btw, my branch is here [1]. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > Pedro Igor > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > To: keycloak-dev(a)lists.jboss.org > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > Authentication > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > Currently adapters can only make authz decisions > > > > > > > > > (@RolesAllowed) > > > > > > > > > based > > > > > > > > > on either realm roles or the roles of one specific > > > > > > > > > application. > > > > > > > > > This > > > > > > > > > is > > > > > > > > > related to 1) too. > > > > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: > > > > > > > > > > 1) Sounds like something definitely worth aiming for. > > > > > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > > > > > > > > > >> I just wanted to quickly list the additional work we > > > > > > > > > >> discussed > > > > > > > > > >> so > > > > > > > > > >> everyone > > > > > > > > > >> can think about it (in no particular order): > > > > > > > > > >> > > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping of an > > > > > > > > > >> external > > > > > > > > > >> token > > > > > > > > > >> to > > > > > > > > > >> a KC token? For example an external token with attribute > > > > > > > > > >> 'group' > > > > > > > > > >> that > > > > > > > > > >> contains 'sales' and 'manager' could be mapped to > > > > > > > > > >> 'manager' > > > > > > > > > >> role > > > > > > > > > >> for > > > > > > > > > >> 'sales app in a KC token. Could we use Drools? This > > > > > > > > > >> could > > > > > > > > > >> also > > > > > > > > > >> be > > > > > > > > > >> used > > > > > > > > > >> in > > > > > > > > > >> user federation to allow more complex mapping of > > > > > > > > > >> roles/groups > > > > > > > > > >> than > > > > > > > > > >> a > > > > > > > > > >> simple 1-1 > > > > > > > > > >> 2) Retrieving tokens - if an application wants to > > > > > > > > > >> retrieve > > > > > > > > > >> the > > > > > > > > > >> external > > > > > > > > > >> token (for example to view Facebook friends if user > > > > > > > > > >> logged > > > > > > > > > >> in > > > > > > > > > >> with > > > > > > > > > >> Facebook) > > > > > > > > > >> 3) Configure scope - currently for social we only > > > > > > > > > >> request > > > > > > > > > >> a > > > > > > > > > >> very > > > > > > > > > >> limited > > > > > > > > > >> scope (basic profile and email), to for example view > > > > > > > > > >> Facebook > > > > > > > > > >> friends > > > > > > > > > >> we'd need to ask for that as well > > > > > > > > > >> 4) Selecting provider - currently in social (and for > > > > > > > > > >> first > > > > > > > > > >> pass > > > > > > > > > >> of > > > > > > > > > >> brokering) we have an icon user has to select, but can > > > > > > > > > >> we > > > > > > > > > >> select > > > > > > > > > >> the > > > > > > > > > >> provider in a different way (for example ask user for > > > > > > > > > >> email, > > > > > > > > > >> and > > > > > > > > > >> select > > > > > > > > > >> based on email domain) > > > > > > > > > >> 5) Gateway - don't create a KC token, but just forward > > > > > > > > > >> the > > > > > > > > > >> external > > > > > > > > > >> token > > > > > > > > > >> > > > > > > > > > >> IMO 1) is a killer feature, as it would allow companies > > > > > > > > > >> to > > > > > > > > > >> add > > > > > > > > > >> external > > > > > > > > > >> users without having to modify their applications. Issue > > > > > > > > > >> with > > > > > > > > > >> 5) > > > > > > > > > >> is > > > > > > > > > >> that > > > > > > > > > >> applications need to understand more than one token, > > > > > > > > > >> which > > > > > > > > > >> would > > > > > > > > > >> require > > > > > > > > > >> rewriting applications. > > > > > > > > > >> > > > > > > > > > >> This work is also somewhat related to other > > > > > > > > > >> authentication > > > > > > > > > >> mechanisms > > > > > > > > > >> (for > > > > > > > > > >> example Kerberos ticket, LDAP and passwordless). > > > > > > > > > >> > > > > > > > > > >> ----- Original Message ----- > > > > > > > > > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > >>> Authentication > > > > > > > > > >>> Broker > > > > > > > > > >>> > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > >>>> Authentication > > > > > > > > > >>>> Broker > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > > > > > > > > > >>>>> Hi, > > > > > > > > > >>>>> > > > > > > > > > >>>>> Would like to start a discussion about how to > > > > > > > > > >>>>> enable > > > > > > > > > >>>>> KC > > > > > > > > > >>>>> as > > > > > > > > > >>>>> an > > > > > > > > > >>>>> Authentication Broker in order to supported > > > > > > > > > >>>>> Chained > > > > > > > > > >>>>> Federation > > > > > > > > > >>>>> and > > > > > > > > > >>>>> also Identity Federation. First of all, some > > > > > > > > > >>>>> background > > > > > > > > > >>>>> about > > > > > > > > > >>>>> what > > > > > > > > > >>>>> this is all about. > > > > > > > > > >>>>> > > > > > > > > > >>>>> Currently KeyCloak provides two basic types of > > > > > > > > > >>>>> authentication > > > > > > > > > >>>>> (correct > > > > > > > > > >>>>> me if I'm wrong, please): > > > > > > > > > >>>>> > > > > > > > > > >>>>> 1) Local authentication (based on some > > > > > > > > > >>>>> credential > > > > > > > > > >>>>> type > > > > > > > > > >>>>> enabled > > > > > > > > > >>>>> to > > > > > > > > > >>>>> a realm) > > > > > > > > > >>>>> 2) Social authentication > > > > > > > > > >>>>> > > > > > > > > > >>>>> Local authentication is about authenticating > > > > > > > > > >>>>> the > > > > > > > > > >>>>> user > > > > > > > > > >>>>> locally > > > > > > > > > >>>>> using > > > > > > > > > >>>>> KC's own identity store. Nothing special here. > > > > > > > > > >>>>> And > > > > > > > > > >>>>> Social > > > > > > > > > >>>>> Authentication which allows users to choose > > > > > > > > > >>>>> the > > > > > > > > > >>>>> Social > > > > > > > > > >>>>> IdP > > > > > > > > > >>>>> they > > > > > > > > > >>>>> want > > > > > > > > > >>>>> to authenticate with. In this case, the IdP is > > > > > > > > > >>>>> always > > > > > > > > > >>>>> one > > > > > > > > > >>>>> of > > > > > > > > > >>>>> the > > > > > > > > > >>>>> built-in social providers supported by KC such > > > > > > > > > >>>>> as > > > > > > > > > >>>>> Facebook, > > > > > > > > > >>>>> Google, > > > > > > > > > >>>>> Twitter, Github and so forth. > > > > > > > > > >>>>> > > > > > > > > > >>>>> When doing social, the user is automatically > > > > > > > > > >>>>> provisioned > > > > > > > > > >>>>> in > > > > > > > > > >>>>> KC > > > > > > > > > >>>>> identity store after a successful > > > > > > > > > >>>>> authentication. > > > > > > > > > >>>>> The > > > > > > > > > >>>>> user > > > > > > > > > >>>>> does > > > > > > > > > >>>>> not > > > > > > > > > >>>>> need to fill a registration form and can > > > > > > > > > >>>>> access > > > > > > > > > >>>>> the > > > > > > > > > >>>>> application > > > > > > > > > >>>>> very > > > > > > > > > >>>>> quickly. During the provisioning some basic > > > > > > > > > >>>>> information > > > > > > > > > >>>>> is > > > > > > > > > >>>>> retrieved > > > > > > > > > >>>>> from the social provider such as email, > > > > > > > > > >>>>> firstname > > > > > > > > > >>>>> and > > > > > > > > > >>>>> so > > > > > > > > > >>>>> forth. > > > > > > > > > >>>>> These > > > > > > > > > >>>>> are very basic information, any other > > > > > > > > > >>>>> information > > > > > > > > > >>>>> such > > > > > > > > > >>>>> as > > > > > > > > > >>>>> those > > > > > > > > > >>>>> related with authorization policies - eg.: > > > > > > > > > >>>>> roles > > > > > > > > > >>>>> and > > > > > > > > > >>>>> groups > > > > > > > > > >>>>> - > > > > > > > > > >>>>> must > > > > > > > > > >>>>> be > > > > > > > > > >>>>> defined later via KC's admin console. > > > > > > > > > >>>>> > > > > > > > > > >>>>> Another important characteristic of social > > > > > > > > > >>>>> authentication > > > > > > > > > >>>>> is > > > > > > > > > >>>>> that > > > > > > > > > >>>>> the > > > > > > > > > >>>>> application receives a KC token and not the > > > > > > > > > >>>>> token > > > > > > > > > >>>>> that > > > > > > > > > >>>>> was > > > > > > > > > >>>>> issued by > > > > > > > > > >>>>> the social IdP during the authentication > > > > > > > > > >>>>> process. > > > > > > > > > >>>>> If > > > > > > > > > >>>>> the > > > > > > > > > >>>>> application > > > > > > > > > >>>>> wants to consume resources from the resource > > > > > > > > > >>>>> provider > > > > > > > > > >>>>> he > > > > > > > > > >>>>> was > > > > > > > > > >>>>> authenticated it must obtain the access > > > > > > > > > >>>>> token(again) > > > > > > > > > >>>>> by > > > > > > > > > >>>>> itself > > > > > > > > > >>>>> prior > > > > > > > > > >>>>> to invoke the resource provider API. Assuming > > > > > > > > > >>>>> all > > > > > > > > > >>>>> those > > > > > > > > > >>>>> social > > > > > > > > > >>>>> providers are based on oAuth 1.0 or 2.0. > > > > > > > > > >>>>> > > > > > > > > > >>>>> That said, the Authentication Broker > > > > > > > > > >>>>> functionality > > > > > > > > > >>>>> aims > > > > > > > > > >>>>> to > > > > > > > > > >>>>> cover > > > > > > > > > >>>>> the > > > > > > > > > >>>>> same use cases but with a lot of more > > > > > > > > > >>>>> flexibility > > > > > > > > > >>>>> on > > > > > > > > > >>>>> how > > > > > > > > > >>>>> you > > > > > > > > > >>>>> setup > > > > > > > > > >>>>> identity providers(not only social ones) and > > > > > > > > > >>>>> the > > > > > > > > > >>>>> different > > > > > > > > > >>>>> federation > > > > > > > > > >>>>> protocols they may support such as SAML, > > > > > > > > > >>>>> OpenID, > > > > > > > > > >>>>> oAuth > > > > > > > > > >>>>> and > > > > > > > > > >>>>> so > > > > > > > > > >>>>> forth. > > > > > > > > > >>>>> This is useful when an enterprise is providing > > > > > > > > > >>>>> services > > > > > > > > > >>>>> to > > > > > > > > > >>>>> different > > > > > > > > > >>>>> customers(IdP) and does not want to manage > > > > > > > > > >>>>> many > > > > > > > > > >>>>> to > > > > > > > > > >>>>> many > > > > > > > > > >>>>> relationships. When using a broker, the > > > > > > > > > >>>>> authentication > > > > > > > > > >>>>> steps > > > > > > > > > >>>>> are > > > > > > > > > >>>>> pretty much the same when you are using social > > > > > > > > > >>>>> authentication, > > > > > > > > > >>>>> with > > > > > > > > > >>>>> important differences on how you support > > > > > > > > > >>>>> different > > > > > > > > > >>>>> identity > > > > > > > > > >>>>> providers, different federation protocols, how > > > > > > > > > >>>>> users > > > > > > > > > >>>>> are > > > > > > > > > >>>>> provisioned > > > > > > > > > >>>>> and how claims and attributes are resolved. > > > > > > > > > >>>>> > > > > > > > > > >>>>> The brokering functionality can be done in two > > > > > > > > > >>>>> ways > > > > > > > > > >>>>> depending > > > > > > > > > >>>>> if > > > > > > > > > >>>>> the > > > > > > > > > >>>>> broker service is acting as a gateway or not. > > > > > > > > > >>>>> When > > > > > > > > > >>>>> acting > > > > > > > > > >>>>> as > > > > > > > > > >>>>> a > > > > > > > > > >>>>> gateway, the broker will respond to the > > > > > > > > > >>>>> application > > > > > > > > > >>>>> the > > > > > > > > > >>>>> same > > > > > > > > > >>>>> token > > > > > > > > > >>>>> issued by the trusted identity provider. For > > > > > > > > > >>>>> instance, > > > > > > > > > >>>>> if > > > > > > > > > >>>>> the > > > > > > > > > >>>>> user > > > > > > > > > >>>>> selects a SAML IdP to authenticate with, the > > > > > > > > > >>>>> application > > > > > > > > > >>>>> will > > > > > > > > > >>>>> receive > > > > > > > > > >>>>> a SAML Response. In this case, the application > > > > > > > > > >>>>> must > > > > > > > > > >>>>> also > > > > > > > > > >>>>> be > > > > > > > > > >>>>> prepared > > > > > > > > > >>>>> to handle a specific federation protocol. > > > > > > > > > >>>>> > > > > > > > > > >>>>> However, the broker service can also be used > > > > > > > > > >>>>> to > > > > > > > > > >>>>> completely > > > > > > > > > >>>>> abstract > > > > > > > > > >>>>> from the application the protocol used to > > > > > > > > > >>>>> authenticate > > > > > > > > > >>>>> an > > > > > > > > > >>>>> user. > > > > > > > > > >>>>> In > > > > > > > > > >>>>> this case, the application will just receive > > > > > > > > > >>>>> an > > > > > > > > > >>>>> ordinary > > > > > > > > > >>>>> KC > > > > > > > > > >>>>> token > > > > > > > > > >>>>> after a successful authentication. > > > > > > > > > >>>>> > > > > > > > > > >>>>> In both cases, the broker acts as an > > > > > > > > > >>>>> intermediary > > > > > > > > > >>>>> where > > > > > > > > > >>>>> specific > > > > > > > > > >>>>> security policies can be applied when users > > > > > > > > > >>>>> try > > > > > > > > > >>>>> to > > > > > > > > > >>>>> authenticate > > > > > > > > > >>>>> themselves against a 3rd party IdP. That > > > > > > > > > >>>>> brings > > > > > > > > > >>>>> a > > > > > > > > > >>>>> lot > > > > > > > > > >>>>> of > > > > > > > > > >>>>> value > > > > > > > > > >>>>> when > > > > > > > > > >>>>> you think about auditing, authorization and > > > > > > > > > >>>>> how > > > > > > > > > >>>>> users > > > > > > > > > >>>>> are > > > > > > > > > >>>>> provisioned > > > > > > > > > >>>>> when federation of identities is needed. This > > > > > > > > > >>>>> also > > > > > > > > > >>>>> allows > > > > > > > > > >>>>> existing > > > > > > > > > >>>>> security infrastructures (eg.: SAML-based > > > > > > > > > >>>>> infrastructures) > > > > > > > > > >>>>> to > > > > > > > > > >>>>> benefit > > > > > > > > > >>>>> from KC's support for cloud, rest and mobile > > > > > > > > > >>>>> use > > > > > > > > > >>>>> cases. > > > > > > > > > >>>>> > > > > > > > > > >>>>> I think this is enough to start a discussion. > > > > > > > > > >>>>> I've > > > > > > > > > >>>>> an > > > > > > > > > >>>>> initial > > > > > > > > > >>>>> discussion with Stian about all that and we > > > > > > > > > >>>>> agreed > > > > > > > > > >>>>> that > > > > > > > > > >>>>> abstract > > > > > > > > > >>>>> the > > > > > > > > > >>>>> protocol from applications should be > > > > > > > > > >>>>> prioritized. > > > > > > > > > >>>>> The > > > > > > > > > >>>>> main > > > > > > > > > >>>>> reason is > > > > > > > > > >>>>> that it makes life easier for applications so > > > > > > > > > >>>>> they > > > > > > > > > >>>>> only > > > > > > > > > >>>>> need > > > > > > > > > >>>>> to > > > > > > > > > >>>>> know > > > > > > > > > >>>>> about KC tokens and nothing else. However that > > > > > > > > > >>>>> brings > > > > > > > > > >>>>> some > > > > > > > > > >>>>> new > > > > > > > > > >>>>> requirements around user provisioning and > > > > > > > > > >>>>> claim/attribute > > > > > > > > > >>>>> resolution > > > > > > > > > >>>>> or mapping. But that would be another thread. > > > > > > > > > >>>>> > > > > > > > > > >>>> > > > > > > > > > >>>> Can you elaborate on "abstract the protocol from > > > > > > > > > >>>> applications"? > > > > > > > > > >>>> Not > > > > > > > > > >>>> sure what you mean by that. IDP federation should be > > > > > > > > > >>>> configured > > > > > > > > > >>>> at > > > > > > > > > >>>> the > > > > > > > > > >>>> realm level and really has nothing to do with > > > > > > > > > >>>> applications. > > > > > > > > > >>>> > > > > > > > > > >>>> I'm really happy that somebody is doing this. We're > > > > > > > > > >>>> getting > > > > > > > > > >>>> a > > > > > > > > > >>>> real > > > > > > > > > >>>> impressive feature set! > > > > > > > > > >>> > > > > > > > > > >>> Sure. What I meant was that the application only knows > > > > > > > > > >>> about > > > > > > > > > >>> KC > > > > > > > > > >>> tokens > > > > > > > > > >>> nothing else. It will always receive a KC token > > > > > > > > > >>> regardless > > > > > > > > > >>> the > > > > > > > > > >>> protocol > > > > > > > > > >>> used > > > > > > > > > >>> to authenticate the user against a 3rd party IdP (saml, > > > > > > > > > >>> oidc, > > > > > > > > > >>> whatever). > > > > > > > > > >>> The > > > > > > > > > >>> example I gave was about an user trying to authenticate > > > > > > > > > >>> against > > > > > > > > > >>> a > > > > > > > > > >>> SAML > > > > > > > > > >>> IdP. > > > > > > > > > >>> In this case, after a successful authentication on the > > > > > > > > > >>> IdP, > > > > > > > > > >>> the > > > > > > > > > >>> IdP > > > > > > > > > >>> will > > > > > > > > > >>> issue a token to KC. Then KC will validate the token, > > > > > > > > > >>> perform > > > > > > > > > >>> trust > > > > > > > > > >>> and > > > > > > > > > >>> security checks, do user provisioning and > > > > > > > > > >>> attribute/claim > > > > > > > > > >>> resolution > > > > > > > > > >>> to > > > > > > > > > >>> finally issue a KC token and redirect the user to the > > > > > > > > > >>> application. > > > > > > > > > >>> If > > > > > > > > > >>> the > > > > > > > > > >>> app is configured to use openid in KC then it will > > > > > > > > > >>> receive > > > > > > > > > >>> a > > > > > > > > > >>> openid > > > > > > > > > >>> token > > > > > > > > > >>> from KC, not saml ... > > > > > > > > > >>> > > > > > > > > > >>> The other scenario is pretty much the same. The > > > > > > > > > >>> difference > > > > > > > > > >>> is > > > > > > > > > >>> that > > > > > > > > > >>> KC > > > > > > > > > >>> will > > > > > > > > > >>> not issue its own token but just replay the token > > > > > > > > > >>> issued > > > > > > > > > >>> by > > > > > > > > > >>> the > > > > > > > > > >>> 3rd > > > > > > > > > >>> party > > > > > > > > > >>> IdP to the service provider. > > > > > > > > > >>> > > > > > > > > > >>> I agree that this config goes at the realm level. For > > > > > > > > > >>> instance, > > > > > > > > > >>> to > > > > > > > > > >>> create > > > > > > > > > >>> and > > > > > > > > > >>> enable providers for being used. However, I think we > > > > > > > > > >>> would > > > > > > > > > >>> need > > > > > > > > > >>> some > > > > > > > > > >>> specific configuration for applications as well. > > > > > > > > > >>> Specially > > > > > > > > > >>> when > > > > > > > > > >>> defining > > > > > > > > > >>> default roles, mapping attributes. Another example of > > > > > > > > > >>> application > > > > > > > > > >>> config > > > > > > > > > >>> is > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to define > > > > > > > > > >>> scopes > > > > > > > > > >>> per-application. > > > > > > > > > >>> > > > > > > > > > >>>> > > > > > > > > > >>>> -- > > > > > > > > > >>>> Bill Burke > > > > > > > > > >>>> JBoss, a division of Red Hat > > > > > > > > > >>>> http://bill.burkecentral.com > > > > > > > > > >>>> _______________________________________________ > > > > > > > > > >>>> keycloak-dev mailing list > > > > > > > > > >>>> keycloak-dev(a)lists.jboss.org > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > >>>> > > > > > > > > > >>> _______________________________________________ > > > > > > > > > >>> keycloak-dev mailing list > > > > > > > > > >>> keycloak-dev(a)lists.jboss.org > > > > > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > >>> > > > > > > > > > >> _______________________________________________ > > > > > > > > > >> keycloak-dev mailing list > > > > > > > > > >> keycloak-dev(a)lists.jboss.org > > > > > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Bill Burke > > > > > > > > > JBoss, a division of Red Hat > > > > > > > > > http://bill.burkecentral.com > > > > > > > > > _______________________________________________ > > > > > > > > > keycloak-dev mailing list > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > keycloak-dev mailing list > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > keycloak-dev mailing list > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > keycloak-dev mailing list > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > >

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Friday, 5 December, 2014 2:28:56 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > Get rid of the social button? Yes, that's the idea. One place to configure Identity Providers in general instead of one for "enterprise" and one for social. Initially I thought keeping social separate would be best, but looking at Pedro's screenshots it seems it would work well to combine the two.

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Friday, 5 December, 2014 2:45:57 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker On 12/5/2014 8:43 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Friday, 5 December, 2014 2:36:14 PM >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >> >> ----- Original Message ----- >>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Friday, December 5, 2014 10:59:08 AM >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>> >>> Another related thing. We've had a few people ask to be able to login to >>> Keycloak on mobiles using the native social login mechanism. >>> >>> I think the best way to do that is to use the direct grant api and make >>> it >>> possible to call that endpoint passing a IdP id and a token instead of >>> username and password. >>> >>> WDYT? >> >> The broker endpoint expects the idp id in order to start the >> authentication >> process. Today, the endpoint also expects KCs authorization code in order >> to >> validate requests from clients and use it as a state to validate responses >> from the trusted idps. >> >> This authorization code is a blocker for this use case, given that mobile >> don't have this code and just want to start the authentication. >> >> A possible solution would be to change the broker to also accept a >> client_id >> to reference the mobile app and perform some validations based on that. >> Something like that: >> >> 1) Mobile displays a Facebook button >> 2) User clicks the button and mobile sends a request to KC Broker with the >> idp id and his client_id. >> 3) KC Broker checks if the client_id is valid and creates a temporary >> authorization code. >> 4) KC Broker redirect mobile to the chosen IdP to perform authentication. >> 5) KC Broker receives a response from the IdP, generate its own token and >> send it back to mobile >> >> Makes sense ? > > No that's not the flow I had in mind. Basically the mobile app > authenticates with Facebook through the native mechanisms. The app then > has an access token, which it would send to Keycloak on the direct grant > api to obtain a Keycloak token. > > Same for other identity providers, the assumption is the app has an out of > bounds mechanism to obtain an access token, which is then sent to Keycloak > over the direct grant api. > How would/could that work exactly? Do social providers sign the token somehow? Can the token be verified?

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Friday, 5 December, 2014 2:45:57 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > On 12/5/2014 8:43 AM, Stian Thorgersen wrote: >> >> >> ----- Original Message ----- >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Friday, 5 December, 2014 2:36:14 PM >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>> >>> ----- Original Message ----- >>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)lists.jboss.org >>>> Sent: Friday, December 5, 2014 10:59:08 AM >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>>> >>>> Another related thing. We've had a few people ask to be able to login to >>>> Keycloak on mobiles using the native social login mechanism. >>>> >>>> I think the best way to do that is to use the direct grant api and make >>>> it >>>> possible to call that endpoint passing a IdP id and a token instead of >>>> username and password. >>>> >>>> WDYT? >>> >>> The broker endpoint expects the idp id in order to start the >>> authentication >>> process. Today, the endpoint also expects KCs authorization code in order >>> to >>> validate requests from clients and use it as a state to validate responses >>> from the trusted idps. >>> >>> This authorization code is a blocker for this use case, given that mobile >>> don't have this code and just want to start the authentication. >>> >>> A possible solution would be to change the broker to also accept a >>> client_id >>> to reference the mobile app and perform some validations based on that. >>> Something like that: >>> >>> 1) Mobile displays a Facebook button >>> 2) User clicks the button and mobile sends a request to KC Broker with the >>> idp id and his client_id. >>> 3) KC Broker checks if the client_id is valid and creates a temporary >>> authorization code. >>> 4) KC Broker redirect mobile to the chosen IdP to perform authentication. >>> 5) KC Broker receives a response from the IdP, generate its own token and >>> send it back to mobile >>> >>> Makes sense ? >> >> No that's not the flow I had in mind. Basically the mobile app >> authenticates with Facebook through the native mechanisms. The app then >> has an access token, which it would send to Keycloak on the direct grant >> api to obtain a Keycloak token. >> >> Same for other identity providers, the assumption is the app has an out of >> bounds mechanism to obtain an access token, which is then sent to Keycloak >> over the direct grant api. >> > > How would/could that work exactly? Do social providers sign the token > somehow? Can the token be verified? I think we should invoke the IdP to verify the token rather than verify it locally. All the social providers we have at the moment first retrieve a token, then use it to obtain the user profile. I assumed we'd just skip the first step and just use the supplied token to retrieve the user profile. For OpenID Connect providers there's the UserInfo endpoint that can be used. That'll both verify the token as well as provide us with the user profile. Not sure about SAML.

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, 5 December, 2014 2:57:46 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, December 5, 2014 11:43:32 AM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Friday, 5 December, 2014 2:36:14 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Friday, December 5, 2014 10:59:08 AM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > Another related thing. We've had a few people ask to be able to login > > > to > > > Keycloak on mobiles using the native social login mechanism. > > > > > > I think the best way to do that is to use the direct grant api and make > > > it > > > possible to call that endpoint passing a IdP id and a token instead of > > > username and password. > > > > > > WDYT? > > > > The broker endpoint expects the idp id in order to start the > > authentication > > process. Today, the endpoint also expects KCs authorization code in order > > to > > validate requests from clients and use it as a state to validate > > responses > > from the trusted idps. > > > > This authorization code is a blocker for this use case, given that mobile > > don't have this code and just want to start the authentication. > > > > A possible solution would be to change the broker to also accept a > > client_id > > to reference the mobile app and perform some validations based on that. > > Something like that: > > > > 1) Mobile displays a Facebook button > > 2) User clicks the button and mobile sends a request to KC Broker with > > the > > idp id and his client_id. > > 3) KC Broker checks if the client_id is valid and creates a temporary > > authorization code. > > 4) KC Broker redirect mobile to the chosen IdP to perform authentication. > > 5) KC Broker receives a response from the IdP, generate its own token and > > send it back to mobile > > > > Makes sense ? > > No that's not the flow I had in mind. Basically the mobile app > authenticates > with Facebook through the native mechanisms. The app then has an access > token, which it would send to Keycloak on the direct grant api to obtain a > Keycloak token. Ahh, now I get what you mean :) Yes, what you said is enough. Then we just need to validate the access token (eg.: using a tokeninfo endpoint). But I think we can also consider that use case I mentioned. You may want to login without forcing the user to redirect to KC login page.

> > Same for other identity providers, the assumption is the app has an out of > bounds mechanism to obtain an access token, which is then sent to Keycloak > over the direct grant api. > > > > > > > > > ----- Original Message ----- > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Friday, 5 December, 2014 1:45:24 PM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > ----- Original Message ----- > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Friday, December 5, 2014 10:22:10 AM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > Looks good. I reckon we can combine the two pages. What about if > > > > > the > > > > > 'Add > > > > > provider' drop-down is: > > > > > > > > > > OpenID > > > > > SAML > > > > > ------ > > > > > Google > > > > > GitHub > > > > > Facebook > > > > > Twitter > > > > > > > > > > Let's drop social on/off and instead have a enable/disable button > > > > > on > > > > > each > > > > > provider. > > > > > > > > Sure. > > > > > > > > > > > > > > Also, would be nice if users could set a name or alias for a > > > > > provider > > > > > instance. This would make the callback url easier to use (instead > > > > > of > > > > > callback/<UUID> it's callback/<alias>). The user federation > > > > > providers > > > > > have > > > > > this. > > > > > > > > One of my first tries was using an alias, just like that. But I > > > > preferred > > > > using the UUID and make the configuration more easier. Beside that, > > > > the > > > > callback url is just a copy and paste, so I think an alias would not > > > > bring > > > > so much usability, but add one more step when configuring providers. > > > > > > > > However, if this is an usability requirement for KC I can change > > > > that. > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > In one of our last discussions, you suggested to leave Social as > > > > > > it > > > > > > is. > > > > > > Although IMO I think we can have a single place to manage both > > > > > > social > > > > > > and > > > > > > user-defined identity providers. Social ones are just OOTB and > > > > > > pre-configured identity providers now. > > > > > > > > > > > > That said, today I'm using separated tabs for social and > > > > > > user-defined. > > > > > > Please, take a look at [1] for more details on how the UI looks > > > > > > like. > > > > > > > > > > > > I've changed social UI a bit in order to provide a specific page > > > > > > for > > > > > > create/update. I've also added a "Show Secret" link to display > > > > > > the > > > > > > client_secret in clear text if user wants to. > > > > > > > > > > > > Beside the enable/disable button, I think another good thing to > > > > > > do > > > > > > is > > > > > > specify > > > > > > a default role(s) for each provider. That can be useful if > > > > > > applications > > > > > > want > > > > > > to perform any kind of authorization based on the identity > > > > > > provider > > > > > > or > > > > > > authentication method used to authenticate an user (eg.: useful > > > > > > for > > > > > > adaptative or multi-level access control). We can also use the > > > > > > "amr" > > > > > > claim > > > > > > in the ID Token, which seems KC is not considering at all. The > > > > > > latter > > > > > > is > > > > > > an > > > > > > important thing to think of, regardless this broker work I'm > > > > > > doing. > > > > > > > > > > > > [1] > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sha... > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > Having a separate enable/disable for each provider would be good. > > > > > > If > > > > > > you're > > > > > > leaving the social tab as is and adding a separate tab for > > > > > > configuring > > > > > > brokered idp's then we should leave the social enable/disable > > > > > > button, > > > > > > otherwise it depends how it'll look like in the end. > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Social has a button to enable/disable it. I'm wondering what > > > > > > > to > > > > > > > do > > > > > > > with > > > > > > > the brokered identity providers. Shall we add a similar flag > > > > > > > for > > > > > > > that > > > > > > > ? > > > > > > > > > > > > > > I was also wondering if the best would be a flag in a per > > > > > > > provider > > > > > > > basis. > > > > > > > So we can disable/enable a specific provider (social or > > > > > > > brokered), > > > > > > > instead of doing that for all. > > > > > > > > > > > > > > Regards. > > > > > > > Pedro Igor > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > Authentication > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > Authentication > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > I'll go for it then. Will remove the icon url from the > > > > > > > > > model > > > > > > > > > and > > > > > > > > > leave > > > > > > > > > that > > > > > > > > > for users if they want to provide icons for their identity > > > > > > > > > providers. > > > > > > > > > > > > > > > > > > My point is that icons can be usually served by the same > > > > > > > > > server/application > > > > > > > > > or proxy, so download images are not such a big deal. Also, > > > > > > > > > the > > > > > > > > > icon > > > > > > > > > url > > > > > > > > > is > > > > > > > > > part of the freemarker model and people can do what ever > > > > > > > > > they > > > > > > > > > want > > > > > > > > > with > > > > > > > > > it. > > > > > > > > > What I think will also help in your future plans. > > > > > > > > > > > > > > > > I'm not following. Are you saying that if a named image > > > > > > > > 'my-provider.png' > > > > > > > > is > > > > > > > > loaded from a theme, then you can override it in another > > > > > > > > theme? > > > > > > > > > > > > > > > > If so, that's basically the same as having a css class > > > > > > > > 'my-provider' > > > > > > > > in > > > > > > > > a > > > > > > > > theme. With the exception that with an image you end up with > > > > > > > > having > > > > > > > > to > > > > > > > > require a image per provider per theme per language, which > > > > > > > > could > > > > > > > > be > > > > > > > > a > > > > > > > > lot > > > > > > > > of > > > > > > > > images for a single provider. Also, buttons for accessibility > > > > > > > > should > > > > > > > > be > > > > > > > > defined with text and css, not images that can't be > > > > > > > > interpreted. > > > > > > > > You > > > > > > > > also > > > > > > > > still need to modify the theme, so I don't see any benefits. > > > > > > > > > > > > > > You are right. Having a icon url per provider does not makes > > > > > > > sense > > > > > > > if > > > > > > > there > > > > > > > are requirements to change images accordingly to a theme or > > > > > > > language. > > > > > > > CSS > > > > > > > makes life easier. > > > > > > > > > > > > > > Will remove that property from the model. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > Authentication > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > Authentication > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > Users can now specify a Icon Url to be rendered on the > > > > > > > > > > login > > > > > > > > > > page > > > > > > > > > > when > > > > > > > > > > social > > > > > > > > > > or any other identity provider is configured. So we just > > > > > > > > > > load > > > > > > > > > > the > > > > > > > > > > image > > > > > > > > > > the > > > > > > > > > > url entered by the user. > > > > > > > > > > > > > > > > > > > > Are you saying that users should change the theme or > > > > > > > > > > customize > > > > > > > > > > css > > > > > > > > > > if > > > > > > > > > > they > > > > > > > > > > only want to change an icon for a provider ? > > > > > > > > > > > > > > > > > > Yes, there's many issues with having a icon url: > > > > > > > > > > > > > > > > > > * Won't work for internationalization - we don't have this > > > > > > > > > now, > > > > > > > > > but > > > > > > > > > we > > > > > > > > > will > > > > > > > > > * Image is not a good button - CSS is much better > > > > > > > > > * Doesn't support themes - we allow users to switch l&f by > > > > > > > > > switching > > > > > > > > > themes, > > > > > > > > > but that won't work for a icon url. In the future we may > > > > > > > > > also > > > > > > > > > support > > > > > > > > > multiple themes per-realm, for example to depending on the > > > > > > > > > devices > > > > > > > > > (one > > > > > > > > > theme for mobiles, one for desktops, etc) > > > > > > > > > * Requires the URL to be hosted somewhere - why require a > > > > > > > > > separate > > > > > > > > > call > > > > > > > > > to > > > > > > > > > download an image (to a separate server maybe) if it can > > > > > > > > > simply > > > > > > > > > be > > > > > > > > > defined > > > > > > > > > in a single CSS file? > > > > > > > > > > > > > > > > > > Rather than add additional places to define look and feel > > > > > > > > > components > > > > > > > > > we > > > > > > > > > should in the future make it easier to add/customize > > > > > > > > > themes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > Authentication > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > All look and feel related things including images and > > > > > > > > > > stylesheets > > > > > > > > > > should > > > > > > > > > > be > > > > > > > > > > part of themes. This is to allow customizing them in the > > > > > > > > > > theme. > > > > > > > > > > Also, > > > > > > > > > > an > > > > > > > > > > image is not the correct way to render a button, it > > > > > > > > > > should > > > > > > > > > > be > > > > > > > > > > defined > > > > > > > > > > in > > > > > > > > > > CSS. > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > Authentication > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > You shouldn't have icon images for social providers. > > > > > > > > > > > They > > > > > > > > > > > should > > > > > > > > > > > be > > > > > > > > > > > specified > > > > > > > > > > > as part of the theme in CSS as is now. > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > Authentication > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > Anyone know where I can get the icons images for > > > > > > > > > > > > social > > > > > > > > > > > > providers > > > > > > > > > > > > ? > > > > > > > > > > > > It > > > > > > > > > > > > seems zocial defines them encoded in some way in > > > > > > > > > > > > CSS. > > > > > > > > > > > > I > > > > > > > > > > > > need > > > > > > > > > > > > that > > > > > > > > > > > > to > > > > > > > > > > > > provide default images if user does not specify > > > > > > > > > > > > their > > > > > > > > > > > > own. > > > > > > > > > > > > > > > > > > > > > > > > Or is still possible to use zocial ones ? > > > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > Authentication > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > > > > > > > > > I've done some initial work covering both > > > > > > > > > > > > persistence > > > > > > > > > > > > and > > > > > > > > > > > > brokering. > > > > > > > > > > > > No > > > > > > > > > > > > UI, yet. I'm focused on the model, rest api and > > > > > > > > > > > > brokering > > > > > > > > > > > > functionality > > > > > > > > > > > > for now. > > > > > > > > > > > > > > > > > > > > > > > > What I have is enough to decide if we are aligned > > > > > > > > > > > > about > > > > > > > > > > > > this > > > > > > > > > > > > functionality. So you can understand how the model > > > > > > > > > > > > (and > > > > > > > > > > > > persistence), > > > > > > > > > > > > rest api and brokering functionality looks like. > > > > > > > > > > > > Can > > > > > > > > > > > > we > > > > > > > > > > > > schedule > > > > > > > > > > > > a > > > > > > > > > > > > meeting ? > > > > > > > > > > > > > > > > > > > > > > > > Btw, my branch is here [1]. > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > Pedro Igor > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > To: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > Authentication > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > Currently adapters can only make authz decisions > > > > > > > > > > > > (@RolesAllowed) > > > > > > > > > > > > based > > > > > > > > > > > > on either realm roles or the roles of one specific > > > > > > > > > > > > application. > > > > > > > > > > > > This > > > > > > > > > > > > is > > > > > > > > > > > > related to 1) too. > > > > > > > > > > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: > > > > > > > > > > > > > 1) Sounds like something definitely worth aiming > > > > > > > > > > > > > for. > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > > > > > > > > > > > > >> I just wanted to quickly list the additional work > > > > > > > > > > > > >> we > > > > > > > > > > > > >> discussed > > > > > > > > > > > > >> so > > > > > > > > > > > > >> everyone > > > > > > > > > > > > >> can think about it (in no particular order): > > > > > > > > > > > > >> > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with mapping > > > > > > > > > > > > >> of > > > > > > > > > > > > >> an > > > > > > > > > > > > >> external > > > > > > > > > > > > >> token > > > > > > > > > > > > >> to > > > > > > > > > > > > >> a KC token? For example an external token with > > > > > > > > > > > > >> attribute > > > > > > > > > > > > >> 'group' > > > > > > > > > > > > >> that > > > > > > > > > > > > >> contains 'sales' and 'manager' could be mapped to > > > > > > > > > > > > >> 'manager' > > > > > > > > > > > > >> role > > > > > > > > > > > > >> for > > > > > > > > > > > > >> 'sales app in a KC token. Could we use Drools? > > > > > > > > > > > > >> This > > > > > > > > > > > > >> could > > > > > > > > > > > > >> also > > > > > > > > > > > > >> be > > > > > > > > > > > > >> used > > > > > > > > > > > > >> in > > > > > > > > > > > > >> user federation to allow more complex mapping of > > > > > > > > > > > > >> roles/groups > > > > > > > > > > > > >> than > > > > > > > > > > > > >> a > > > > > > > > > > > > >> simple 1-1 > > > > > > > > > > > > >> 2) Retrieving tokens - if an application wants to > > > > > > > > > > > > >> retrieve > > > > > > > > > > > > >> the > > > > > > > > > > > > >> external > > > > > > > > > > > > >> token (for example to view Facebook friends if > > > > > > > > > > > > >> user > > > > > > > > > > > > >> logged > > > > > > > > > > > > >> in > > > > > > > > > > > > >> with > > > > > > > > > > > > >> Facebook) > > > > > > > > > > > > >> 3) Configure scope - currently for social we only > > > > > > > > > > > > >> request > > > > > > > > > > > > >> a > > > > > > > > > > > > >> very > > > > > > > > > > > > >> limited > > > > > > > > > > > > >> scope (basic profile and email), to for example > > > > > > > > > > > > >> view > > > > > > > > > > > > >> Facebook > > > > > > > > > > > > >> friends > > > > > > > > > > > > >> we'd need to ask for that as well > > > > > > > > > > > > >> 4) Selecting provider - currently in social (and > > > > > > > > > > > > >> for > > > > > > > > > > > > >> first > > > > > > > > > > > > >> pass > > > > > > > > > > > > >> of > > > > > > > > > > > > >> brokering) we have an icon user has to select, but > > > > > > > > > > > > >> can > > > > > > > > > > > > >> we > > > > > > > > > > > > >> select > > > > > > > > > > > > >> the > > > > > > > > > > > > >> provider in a different way (for example ask user > > > > > > > > > > > > >> for > > > > > > > > > > > > >> email, > > > > > > > > > > > > >> and > > > > > > > > > > > > >> select > > > > > > > > > > > > >> based on email domain) > > > > > > > > > > > > >> 5) Gateway - don't create a KC token, but just > > > > > > > > > > > > >> forward > > > > > > > > > > > > >> the > > > > > > > > > > > > >> external > > > > > > > > > > > > >> token > > > > > > > > > > > > >> > > > > > > > > > > > > >> IMO 1) is a killer feature, as it would allow > > > > > > > > > > > > >> companies > > > > > > > > > > > > >> to > > > > > > > > > > > > >> add > > > > > > > > > > > > >> external > > > > > > > > > > > > >> users without having to modify their applications. > > > > > > > > > > > > >> Issue > > > > > > > > > > > > >> with > > > > > > > > > > > > >> 5) > > > > > > > > > > > > >> is > > > > > > > > > > > > >> that > > > > > > > > > > > > >> applications need to understand more than one > > > > > > > > > > > > >> token, > > > > > > > > > > > > >> which > > > > > > > > > > > > >> would > > > > > > > > > > > > >> require > > > > > > > > > > > > >> rewriting applications. > > > > > > > > > > > > >> > > > > > > > > > > > > >> This work is also somewhat related to other > > > > > > > > > > > > >> authentication > > > > > > > > > > > > >> mechanisms > > > > > > > > > > > > >> (for > > > > > > > > > > > > >> example Kerberos ticket, LDAP and passwordless). > > > > > > > > > > > > >> > > > > > > > > > > > > >> ----- Original Message ----- > > > > > > > > > > > > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > >>> and > > > > > > > > > > > > >>> Authentication > > > > > > > > > > > > >>> Broker > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > > > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 PM > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > >>>> and > > > > > > > > > > > > >>>> Authentication > > > > > > > > > > > > >>>> Broker > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: > > > > > > > > > > > > >>>>> Hi, > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> Would like to start a discussion about > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> enable > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > >>>>> Authentication Broker in order to > > > > > > > > > > > > >>>>> supported > > > > > > > > > > > > >>>>> Chained > > > > > > > > > > > > >>>>> Federation > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > >>>>> also Identity Federation. First of all, > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > >>>>> background > > > > > > > > > > > > >>>>> about > > > > > > > > > > > > >>>>> what > > > > > > > > > > > > >>>>> this is all about. > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> Currently KeyCloak provides two basic > > > > > > > > > > > > >>>>> types > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > >>>>> (correct > > > > > > > > > > > > >>>>> me if I'm wrong, please): > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> 1) Local authentication (based on > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > >>>>> credential > > > > > > > > > > > > >>>>> type > > > > > > > > > > > > >>>>> enabled > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> a realm) > > > > > > > > > > > > >>>>> 2) Social authentication > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> Local authentication is about > > > > > > > > > > > > >>>>> authenticating > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > >>>>> locally > > > > > > > > > > > > >>>>> using > > > > > > > > > > > > >>>>> KC's own identity store. Nothing special > > > > > > > > > > > > >>>>> here. > > > > > > > > > > > > >>>>> And > > > > > > > > > > > > >>>>> Social > > > > > > > > > > > > >>>>> Authentication which allows users to > > > > > > > > > > > > >>>>> choose > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> Social > > > > > > > > > > > > >>>>> IdP > > > > > > > > > > > > >>>>> they > > > > > > > > > > > > >>>>> want > > > > > > > > > > > > >>>>> to authenticate with. In this case, the > > > > > > > > > > > > >>>>> IdP > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > >>>>> always > > > > > > > > > > > > >>>>> one > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> built-in social providers supported by > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > >>>>> Facebook, > > > > > > > > > > > > >>>>> Google, > > > > > > > > > > > > >>>>> Twitter, Github and so forth. > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> When doing social, the user is > > > > > > > > > > > > >>>>> automatically > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > >>>>> in > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > >>>>> identity store after a successful > > > > > > > > > > > > >>>>> authentication. > > > > > > > > > > > > >>>>> The > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > >>>>> does > > > > > > > > > > > > >>>>> not > > > > > > > > > > > > >>>>> need to fill a registration form and can > > > > > > > > > > > > >>>>> access > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > >>>>> very > > > > > > > > > > > > >>>>> quickly. During the provisioning some > > > > > > > > > > > > >>>>> basic > > > > > > > > > > > > >>>>> information > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > >>>>> retrieved > > > > > > > > > > > > >>>>> from the social provider such as email, > > > > > > > > > > > > >>>>> firstname > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > >>>>> forth. > > > > > > > > > > > > >>>>> These > > > > > > > > > > > > >>>>> are very basic information, any other > > > > > > > > > > > > >>>>> information > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > >>>>> those > > > > > > > > > > > > >>>>> related with authorization policies - > > > > > > > > > > > > >>>>> eg.: > > > > > > > > > > > > >>>>> roles > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > >>>>> groups > > > > > > > > > > > > >>>>> - > > > > > > > > > > > > >>>>> must > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > >>>>> defined later via KC's admin console. > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> Another important characteristic of > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> application receives a KC token and not > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > >>>>> was > > > > > > > > > > > > >>>>> issued by > > > > > > > > > > > > >>>>> the social IdP during the authentication > > > > > > > > > > > > >>>>> process. > > > > > > > > > > > > >>>>> If > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > >>>>> wants to consume resources from the > > > > > > > > > > > > >>>>> resource > > > > > > > > > > > > >>>>> provider > > > > > > > > > > > > >>>>> he > > > > > > > > > > > > >>>>> was > > > > > > > > > > > > >>>>> authenticated it must obtain the access > > > > > > > > > > > > >>>>> token(again) > > > > > > > > > > > > >>>>> by > > > > > > > > > > > > >>>>> itself > > > > > > > > > > > > >>>>> prior > > > > > > > > > > > > >>>>> to invoke the resource provider API. > > > > > > > > > > > > >>>>> Assuming > > > > > > > > > > > > >>>>> all > > > > > > > > > > > > >>>>> those > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > >>>>> providers are based on oAuth 1.0 or 2.0. > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> That said, the Authentication Broker > > > > > > > > > > > > >>>>> functionality > > > > > > > > > > > > >>>>> aims > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> cover > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> same use cases but with a lot of more > > > > > > > > > > > > >>>>> flexibility > > > > > > > > > > > > >>>>> on > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > >>>>> you > > > > > > > > > > > > >>>>> setup > > > > > > > > > > > > >>>>> identity providers(not only social ones) > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > >>>>> federation > > > > > > > > > > > > >>>>> protocols they may support such as SAML, > > > > > > > > > > > > >>>>> OpenID, > > > > > > > > > > > > >>>>> oAuth > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > >>>>> forth. > > > > > > > > > > > > >>>>> This is useful when an enterprise is > > > > > > > > > > > > >>>>> providing > > > > > > > > > > > > >>>>> services > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > >>>>> customers(IdP) and does not want to > > > > > > > > > > > > >>>>> manage > > > > > > > > > > > > >>>>> many > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> many > > > > > > > > > > > > >>>>> relationships. When using a broker, the > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > >>>>> steps > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > >>>>> pretty much the same when you are using > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > >>>>> authentication, > > > > > > > > > > > > >>>>> with > > > > > > > > > > > > >>>>> important differences on how you support > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > >>>>> identity > > > > > > > > > > > > >>>>> providers, different federation > > > > > > > > > > > > >>>>> protocols, > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > >>>>> and how claims and attributes are > > > > > > > > > > > > >>>>> resolved. > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> The brokering functionality can be done > > > > > > > > > > > > >>>>> in > > > > > > > > > > > > >>>>> two > > > > > > > > > > > > >>>>> ways > > > > > > > > > > > > >>>>> depending > > > > > > > > > > > > >>>>> if > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> broker service is acting as a gateway or > > > > > > > > > > > > >>>>> not. > > > > > > > > > > > > >>>>> When > > > > > > > > > > > > >>>>> acting > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > >>>>> gateway, the broker will respond to the > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> same > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > >>>>> issued by the trusted identity provider. > > > > > > > > > > > > >>>>> For > > > > > > > > > > > > >>>>> instance, > > > > > > > > > > > > >>>>> if > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > >>>>> selects a SAML IdP to authenticate with, > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > >>>>> will > > > > > > > > > > > > >>>>> receive > > > > > > > > > > > > >>>>> a SAML Response. In this case, the > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > >>>>> must > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > >>>>> prepared > > > > > > > > > > > > >>>>> to handle a specific federation > > > > > > > > > > > > >>>>> protocol. > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> However, the broker service can also be > > > > > > > > > > > > >>>>> used > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> completely > > > > > > > > > > > > >>>>> abstract > > > > > > > > > > > > >>>>> from the application the protocol used > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > >>>>> user. > > > > > > > > > > > > >>>>> In > > > > > > > > > > > > >>>>> this case, the application will just > > > > > > > > > > > > >>>>> receive > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > >>>>> ordinary > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > >>>>> after a successful authentication. > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> In both cases, the broker acts as an > > > > > > > > > > > > >>>>> intermediary > > > > > > > > > > > > >>>>> where > > > > > > > > > > > > >>>>> specific > > > > > > > > > > > > >>>>> security policies can be applied when > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > >>>>> try > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > >>>>> themselves against a 3rd party IdP. That > > > > > > > > > > > > >>>>> brings > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > >>>>> lot > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > >>>>> value > > > > > > > > > > > > >>>>> when > > > > > > > > > > > > >>>>> you think about auditing, authorization > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > >>>>> when federation of identities is needed. > > > > > > > > > > > > >>>>> This > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > >>>>> allows > > > > > > > > > > > > >>>>> existing > > > > > > > > > > > > >>>>> security infrastructures (eg.: > > > > > > > > > > > > >>>>> SAML-based > > > > > > > > > > > > >>>>> infrastructures) > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> benefit > > > > > > > > > > > > >>>>> from KC's support for cloud, rest and > > > > > > > > > > > > >>>>> mobile > > > > > > > > > > > > >>>>> use > > > > > > > > > > > > >>>>> cases. > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>>> I think this is enough to start a > > > > > > > > > > > > >>>>> discussion. > > > > > > > > > > > > >>>>> I've > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > >>>>> initial > > > > > > > > > > > > >>>>> discussion with Stian about all that and > > > > > > > > > > > > >>>>> we > > > > > > > > > > > > >>>>> agreed > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > >>>>> abstract > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > >>>>> protocol from applications should be > > > > > > > > > > > > >>>>> prioritized. > > > > > > > > > > > > >>>>> The > > > > > > > > > > > > >>>>> main > > > > > > > > > > > > >>>>> reason is > > > > > > > > > > > > >>>>> that it makes life easier for > > > > > > > > > > > > >>>>> applications > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > >>>>> they > > > > > > > > > > > > >>>>> only > > > > > > > > > > > > >>>>> need > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > >>>>> know > > > > > > > > > > > > >>>>> about KC tokens and nothing else. > > > > > > > > > > > > >>>>> However > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > >>>>> brings > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > >>>>> new > > > > > > > > > > > > >>>>> requirements around user provisioning > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > >>>>> claim/attribute > > > > > > > > > > > > >>>>> resolution > > > > > > > > > > > > >>>>> or mapping. But that would be another > > > > > > > > > > > > >>>>> thread. > > > > > > > > > > > > >>>>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> Can you elaborate on "abstract the protocol from > > > > > > > > > > > > >>>> applications"? > > > > > > > > > > > > >>>> Not > > > > > > > > > > > > >>>> sure what you mean by that. IDP federation > > > > > > > > > > > > >>>> should > > > > > > > > > > > > >>>> be > > > > > > > > > > > > >>>> configured > > > > > > > > > > > > >>>> at > > > > > > > > > > > > >>>> the > > > > > > > > > > > > >>>> realm level and really has nothing to do with > > > > > > > > > > > > >>>> applications. > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> I'm really happy that somebody is doing this. > > > > > > > > > > > > >>>> We're > > > > > > > > > > > > >>>> getting > > > > > > > > > > > > >>>> a > > > > > > > > > > > > >>>> real > > > > > > > > > > > > >>>> impressive feature set! > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> Sure. What I meant was that the application only > > > > > > > > > > > > >>> knows > > > > > > > > > > > > >>> about > > > > > > > > > > > > >>> KC > > > > > > > > > > > > >>> tokens > > > > > > > > > > > > >>> nothing else. It will always receive a KC token > > > > > > > > > > > > >>> regardless > > > > > > > > > > > > >>> the > > > > > > > > > > > > >>> protocol > > > > > > > > > > > > >>> used > > > > > > > > > > > > >>> to authenticate the user against a 3rd party IdP > > > > > > > > > > > > >>> (saml, > > > > > > > > > > > > >>> oidc, > > > > > > > > > > > > >>> whatever). > > > > > > > > > > > > >>> The > > > > > > > > > > > > >>> example I gave was about an user trying to > > > > > > > > > > > > >>> authenticate > > > > > > > > > > > > >>> against > > > > > > > > > > > > >>> a > > > > > > > > > > > > >>> SAML > > > > > > > > > > > > >>> IdP. > > > > > > > > > > > > >>> In this case, after a successful authentication > > > > > > > > > > > > >>> on > > > > > > > > > > > > >>> the > > > > > > > > > > > > >>> IdP, > > > > > > > > > > > > >>> the > > > > > > > > > > > > >>> IdP > > > > > > > > > > > > >>> will > > > > > > > > > > > > >>> issue a token to KC. Then KC will validate the > > > > > > > > > > > > >>> token, > > > > > > > > > > > > >>> perform > > > > > > > > > > > > >>> trust > > > > > > > > > > > > >>> and > > > > > > > > > > > > >>> security checks, do user provisioning and > > > > > > > > > > > > >>> attribute/claim > > > > > > > > > > > > >>> resolution > > > > > > > > > > > > >>> to > > > > > > > > > > > > >>> finally issue a KC token and redirect the user to > > > > > > > > > > > > >>> the > > > > > > > > > > > > >>> application. > > > > > > > > > > > > >>> If > > > > > > > > > > > > >>> the > > > > > > > > > > > > >>> app is configured to use openid in KC then it > > > > > > > > > > > > >>> will > > > > > > > > > > > > >>> receive > > > > > > > > > > > > >>> a > > > > > > > > > > > > >>> openid > > > > > > > > > > > > >>> token > > > > > > > > > > > > >>> from KC, not saml ... > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> The other scenario is pretty much the same. The > > > > > > > > > > > > >>> difference > > > > > > > > > > > > >>> is > > > > > > > > > > > > >>> that > > > > > > > > > > > > >>> KC > > > > > > > > > > > > >>> will > > > > > > > > > > > > >>> not issue its own token but just replay the token > > > > > > > > > > > > >>> issued > > > > > > > > > > > > >>> by > > > > > > > > > > > > >>> the > > > > > > > > > > > > >>> 3rd > > > > > > > > > > > > >>> party > > > > > > > > > > > > >>> IdP to the service provider. > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> I agree that this config goes at the realm level. > > > > > > > > > > > > >>> For > > > > > > > > > > > > >>> instance, > > > > > > > > > > > > >>> to > > > > > > > > > > > > >>> create > > > > > > > > > > > > >>> and > > > > > > > > > > > > >>> enable providers for being used. However, I think > > > > > > > > > > > > >>> we > > > > > > > > > > > > >>> would > > > > > > > > > > > > >>> need > > > > > > > > > > > > >>> some > > > > > > > > > > > > >>> specific configuration for applications as well. > > > > > > > > > > > > >>> Specially > > > > > > > > > > > > >>> when > > > > > > > > > > > > >>> defining > > > > > > > > > > > > >>> default roles, mapping attributes. Another > > > > > > > > > > > > >>> example > > > > > > > > > > > > >>> of > > > > > > > > > > > > >>> application > > > > > > > > > > > > >>> config > > > > > > > > > > > > >>> is > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to > > > > > > > > > > > > >>> define > > > > > > > > > > > > >>> scopes > > > > > > > > > > > > >>> per-application. > > > > > > > > > > > > >>> > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>>> -- > > > > > > > > > > > > >>>> Bill Burke > > > > > > > > > > > > >>>> JBoss, a division of Red Hat > > > > > > > > > > > > >>>> http://bill.burkecentral.com > > > > > > > > > > > > >>>> _______________________________________________ > > > > > > > > > > > > >>>> keycloak-dev mailing list > > > > > > > > > > > > >>>> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > >>>> > > > > > > > > > > > > >>> _______________________________________________ > > > > > > > > > > > > >>> keycloak-dev mailing list > > > > > > > > > > > > >>> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > >>> > > > > > > > > > > > > >> _______________________________________________ > > > > > > > > > > > > >> keycloak-dev mailing list > > > > > > > > > > > > >> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Bill Burke > > > > > > > > > > > > JBoss, a division of Red Hat > > > > > > > > > > > > http://bill.burkecentral.com > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > keycloak-dev mailing list > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > >

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, 5 December, 2014 3:15:42 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, December 5, 2014 12:07:37 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Friday, 5 December, 2014 2:57:46 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Friday, December 5, 2014 11:43:32 AM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Friday, 5 December, 2014 2:36:14 PM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > ----- Original Message ----- > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Friday, December 5, 2014 10:59:08 AM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > Another related thing. We've had a few people ask to be able to > > > > > login > > > > > to > > > > > Keycloak on mobiles using the native social login mechanism. > > > > > > > > > > I think the best way to do that is to use the direct grant api and > > > > > make > > > > > it > > > > > possible to call that endpoint passing a IdP id and a token instead > > > > > of > > > > > username and password. > > > > > > > > > > WDYT? > > > > > > > > The broker endpoint expects the idp id in order to start the > > > > authentication > > > > process. Today, the endpoint also expects KCs authorization code in > > > > order > > > > to > > > > validate requests from clients and use it as a state to validate > > > > responses > > > > from the trusted idps. > > > > > > > > This authorization code is a blocker for this use case, given that > > > > mobile > > > > don't have this code and just want to start the authentication. > > > > > > > > A possible solution would be to change the broker to also accept a > > > > client_id > > > > to reference the mobile app and perform some validations based on > > > > that. > > > > Something like that: > > > > > > > > 1) Mobile displays a Facebook button > > > > 2) User clicks the button and mobile sends a request to KC Broker > > > > with > > > > the > > > > idp id and his client_id. > > > > 3) KC Broker checks if the client_id is valid and creates a temporary > > > > authorization code. > > > > 4) KC Broker redirect mobile to the chosen IdP to perform > > > > authentication. > > > > 5) KC Broker receives a response from the IdP, generate its own token > > > > and > > > > send it back to mobile > > > > > > > > Makes sense ? > > > > > > No that's not the flow I had in mind. Basically the mobile app > > > authenticates > > > with Facebook through the native mechanisms. The app then has an access > > > token, which it would send to Keycloak on the direct grant api to > > > obtain > > > a > > > Keycloak token. > > > > Ahh, now I get what you mean :) > > > > Yes, what you said is enough. Then we just need to validate the access > > token > > (eg.: using a tokeninfo endpoint). > > > > But I think we can also consider that use case I mentioned. You may want > > to > > login without forcing the user to redirect to KC login page. > > We could just add a query param to the login url that lets you pick the IdP > to use by alias? > > For example auth/.../login?client_id=...&auth_method=google Yes, just like my previously example, we need the client_id. The idp id/alias is already there.

Btw, regarding SAML. SAML does not provide a "validation" endpoint like oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the specs for that. What can be done here is validate SAML assertions against a WS-Trust STS. Or just trust the assertion based on the signature and others standards info along it. We can also take a closer look at the oAuth2 SAML bearer token profile and see if it helps.

> > > > > > > > > Same for other identity providers, the assumption is the app has an out > > > of > > > bounds mechanism to obtain an access token, which is then sent to > > > Keycloak > > > over the direct grant api. > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Friday, 5 December, 2014 1:45:24 PM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Friday, December 5, 2014 10:22:10 AM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > Looks good. I reckon we can combine the two pages. What about > > > > > > > if > > > > > > > the > > > > > > > 'Add > > > > > > > provider' drop-down is: > > > > > > > > > > > > > > OpenID > > > > > > > SAML > > > > > > > ------ > > > > > > > Google > > > > > > > GitHub > > > > > > > Facebook > > > > > > > Twitter > > > > > > > > > > > > > > Let's drop social on/off and instead have a enable/disable > > > > > > > button > > > > > > > on > > > > > > > each > > > > > > > provider. > > > > > > > > > > > > Sure. > > > > > > > > > > > > > > > > > > > > Also, would be nice if users could set a name or alias for a > > > > > > > provider > > > > > > > instance. This would make the callback url easier to use > > > > > > > (instead > > > > > > > of > > > > > > > callback/<UUID> it's callback/<alias>). The user federation > > > > > > > providers > > > > > > > have > > > > > > > this. > > > > > > > > > > > > One of my first tries was using an alias, just like that. But I > > > > > > preferred > > > > > > using the UUID and make the configuration more easier. Beside > > > > > > that, > > > > > > the > > > > > > callback url is just a copy and paste, so I think an alias would > > > > > > not > > > > > > bring > > > > > > so much usability, but add one more step when configuring > > > > > > providers. > > > > > > > > > > > > However, if this is an usability requirement for KC I can change > > > > > > that. > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > Authentication > > > > > > > > Broker > > > > > > > > > > > > > > > > In one of our last discussions, you suggested to leave Social > > > > > > > > as > > > > > > > > it > > > > > > > > is. > > > > > > > > Although IMO I think we can have a single place to manage > > > > > > > > both > > > > > > > > social > > > > > > > > and > > > > > > > > user-defined identity providers. Social ones are just OOTB > > > > > > > > and > > > > > > > > pre-configured identity providers now. > > > > > > > > > > > > > > > > That said, today I'm using separated tabs for social and > > > > > > > > user-defined. > > > > > > > > Please, take a look at [1] for more details on how the UI > > > > > > > > looks > > > > > > > > like. > > > > > > > > > > > > > > > > I've changed social UI a bit in order to provide a specific > > > > > > > > page > > > > > > > > for > > > > > > > > create/update. I've also added a "Show Secret" link to > > > > > > > > display > > > > > > > > the > > > > > > > > client_secret in clear text if user wants to. > > > > > > > > > > > > > > > > Beside the enable/disable button, I think another good thing > > > > > > > > to > > > > > > > > do > > > > > > > > is > > > > > > > > specify > > > > > > > > a default role(s) for each provider. That can be useful if > > > > > > > > applications > > > > > > > > want > > > > > > > > to perform any kind of authorization based on the identity > > > > > > > > provider > > > > > > > > or > > > > > > > > authentication method used to authenticate an user (eg.: > > > > > > > > useful > > > > > > > > for > > > > > > > > adaptative or multi-level access control). We can also use > > > > > > > > the > > > > > > > > "amr" > > > > > > > > claim > > > > > > > > in the ID Token, which seems KC is not considering at all. > > > > > > > > The > > > > > > > > latter > > > > > > > > is > > > > > > > > an > > > > > > > > important thing to think of, regardless this broker work I'm > > > > > > > > doing. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sha... > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > Authentication > > > > > > > > Broker > > > > > > > > > > > > > > > > Having a separate enable/disable for each provider would be > > > > > > > > good. > > > > > > > > If > > > > > > > > you're > > > > > > > > leaving the social tab as is and adding a separate tab for > > > > > > > > configuring > > > > > > > > brokered idp's then we should leave the social enable/disable > > > > > > > > button, > > > > > > > > otherwise it depends how it'll look like in the end. > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > Authentication > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Social has a button to enable/disable it. I'm wondering > > > > > > > > > what > > > > > > > > > to > > > > > > > > > do > > > > > > > > > with > > > > > > > > > the brokered identity providers. Shall we add a similar > > > > > > > > > flag > > > > > > > > > for > > > > > > > > > that > > > > > > > > > ? > > > > > > > > > > > > > > > > > > I was also wondering if the best would be a flag in a > > > > > > > > > per > > > > > > > > > provider > > > > > > > > > basis. > > > > > > > > > So we can disable/enable a specific provider (social or > > > > > > > > > brokered), > > > > > > > > > instead of doing that for all. > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > Pedro Igor > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > Authentication > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > Authentication > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > Authentication > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > I'll go for it then. Will remove the icon url from the > > > > > > > > > > > model > > > > > > > > > > > and > > > > > > > > > > > leave > > > > > > > > > > > that > > > > > > > > > > > for users if they want to provide icons for their > > > > > > > > > > > identity > > > > > > > > > > > providers. > > > > > > > > > > > > > > > > > > > > > > My point is that icons can be usually served by the > > > > > > > > > > > same > > > > > > > > > > > server/application > > > > > > > > > > > or proxy, so download images are not such a big deal. > > > > > > > > > > > Also, > > > > > > > > > > > the > > > > > > > > > > > icon > > > > > > > > > > > url > > > > > > > > > > > is > > > > > > > > > > > part of the freemarker model and people can do what > > > > > > > > > > > ever > > > > > > > > > > > they > > > > > > > > > > > want > > > > > > > > > > > with > > > > > > > > > > > it. > > > > > > > > > > > What I think will also help in your future plans. > > > > > > > > > > > > > > > > > > > > I'm not following. Are you saying that if a named image > > > > > > > > > > 'my-provider.png' > > > > > > > > > > is > > > > > > > > > > loaded from a theme, then you can override it in another > > > > > > > > > > theme? > > > > > > > > > > > > > > > > > > > > If so, that's basically the same as having a css class > > > > > > > > > > 'my-provider' > > > > > > > > > > in > > > > > > > > > > a > > > > > > > > > > theme. With the exception that with an image you end up > > > > > > > > > > with > > > > > > > > > > having > > > > > > > > > > to > > > > > > > > > > require a image per provider per theme per language, > > > > > > > > > > which > > > > > > > > > > could > > > > > > > > > > be > > > > > > > > > > a > > > > > > > > > > lot > > > > > > > > > > of > > > > > > > > > > images for a single provider. Also, buttons for > > > > > > > > > > accessibility > > > > > > > > > > should > > > > > > > > > > be > > > > > > > > > > defined with text and css, not images that can't be > > > > > > > > > > interpreted. > > > > > > > > > > You > > > > > > > > > > also > > > > > > > > > > still need to modify the theme, so I don't see any > > > > > > > > > > benefits. > > > > > > > > > > > > > > > > > > You are right. Having a icon url per provider does not > > > > > > > > > makes > > > > > > > > > sense > > > > > > > > > if > > > > > > > > > there > > > > > > > > > are requirements to change images accordingly to a theme or > > > > > > > > > language. > > > > > > > > > CSS > > > > > > > > > makes life easier. > > > > > > > > > > > > > > > > > > Will remove that property from the model. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > Authentication > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > Authentication > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > Users can now specify a Icon Url to be rendered on > > > > > > > > > > > > the > > > > > > > > > > > > login > > > > > > > > > > > > page > > > > > > > > > > > > when > > > > > > > > > > > > social > > > > > > > > > > > > or any other identity provider is configured. So we > > > > > > > > > > > > just > > > > > > > > > > > > load > > > > > > > > > > > > the > > > > > > > > > > > > image > > > > > > > > > > > > the > > > > > > > > > > > > url entered by the user. > > > > > > > > > > > > > > > > > > > > > > > > Are you saying that users should change the theme or > > > > > > > > > > > > customize > > > > > > > > > > > > css > > > > > > > > > > > > if > > > > > > > > > > > > they > > > > > > > > > > > > only want to change an icon for a provider ? > > > > > > > > > > > > > > > > > > > > > > Yes, there's many issues with having a icon url: > > > > > > > > > > > > > > > > > > > > > > * Won't work for internationalization - we don't have > > > > > > > > > > > this > > > > > > > > > > > now, > > > > > > > > > > > but > > > > > > > > > > > we > > > > > > > > > > > will > > > > > > > > > > > * Image is not a good button - CSS is much better > > > > > > > > > > > * Doesn't support themes - we allow users to switch l&f > > > > > > > > > > > by > > > > > > > > > > > switching > > > > > > > > > > > themes, > > > > > > > > > > > but that won't work for a icon url. In the future we > > > > > > > > > > > may > > > > > > > > > > > also > > > > > > > > > > > support > > > > > > > > > > > multiple themes per-realm, for example to depending on > > > > > > > > > > > the > > > > > > > > > > > devices > > > > > > > > > > > (one > > > > > > > > > > > theme for mobiles, one for desktops, etc) > > > > > > > > > > > * Requires the URL to be hosted somewhere - why require > > > > > > > > > > > a > > > > > > > > > > > separate > > > > > > > > > > > call > > > > > > > > > > > to > > > > > > > > > > > download an image (to a separate server maybe) if it > > > > > > > > > > > can > > > > > > > > > > > simply > > > > > > > > > > > be > > > > > > > > > > > defined > > > > > > > > > > > in a single CSS file? > > > > > > > > > > > > > > > > > > > > > > Rather than add additional places to define look and > > > > > > > > > > > feel > > > > > > > > > > > components > > > > > > > > > > > we > > > > > > > > > > > should in the future make it easier to add/customize > > > > > > > > > > > themes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > Authentication > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > All look and feel related things including images and > > > > > > > > > > > > stylesheets > > > > > > > > > > > > should > > > > > > > > > > > > be > > > > > > > > > > > > part of themes. This is to allow customizing them in > > > > > > > > > > > > the > > > > > > > > > > > > theme. > > > > > > > > > > > > Also, > > > > > > > > > > > > an > > > > > > > > > > > > image is not the correct way to render a button, it > > > > > > > > > > > > should > > > > > > > > > > > > be > > > > > > > > > > > > defined > > > > > > > > > > > > in > > > > > > > > > > > > CSS. > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > You shouldn't have icon images for social > > > > > > > > > > > > > providers. > > > > > > > > > > > > > They > > > > > > > > > > > > > should > > > > > > > > > > > > > be > > > > > > > > > > > > > specified > > > > > > > > > > > > > as part of the theme in CSS as is now. > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > > > and > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anyone know where I can get the icons images > > > > > > > > > > > > > > for > > > > > > > > > > > > > > social > > > > > > > > > > > > > > providers > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > It > > > > > > > > > > > > > > seems zocial defines them encoded in some way > > > > > > > > > > > > > > in > > > > > > > > > > > > > > CSS. > > > > > > > > > > > > > > I > > > > > > > > > > > > > > need > > > > > > > > > > > > > > that > > > > > > > > > > > > > > to > > > > > > > > > > > > > > provide default images if user does not > > > > > > > > > > > > > > specify > > > > > > > > > > > > > > their > > > > > > > > > > > > > > own. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or is still possible to use zocial ones ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > > > and > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've done some initial work covering both > > > > > > > > > > > > > > persistence > > > > > > > > > > > > > > and > > > > > > > > > > > > > > brokering. > > > > > > > > > > > > > > No > > > > > > > > > > > > > > UI, yet. I'm focused on the model, rest api > > > > > > > > > > > > > > and > > > > > > > > > > > > > > brokering > > > > > > > > > > > > > > functionality > > > > > > > > > > > > > > for now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > What I have is enough to decide if we are > > > > > > > > > > > > > > aligned > > > > > > > > > > > > > > about > > > > > > > > > > > > > > this > > > > > > > > > > > > > > functionality. So you can understand how the > > > > > > > > > > > > > > model > > > > > > > > > > > > > > (and > > > > > > > > > > > > > > persistence), > > > > > > > > > > > > > > rest api and brokering functionality looks > > > > > > > > > > > > > > like. > > > > > > > > > > > > > > Can > > > > > > > > > > > > > > we > > > > > > > > > > > > > > schedule > > > > > > > > > > > > > > a > > > > > > > > > > > > > > meeting ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Btw, my branch is here [1]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > Pedro Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > To: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > > > and > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > Currently adapters can only make authz decisions > > > > > > > > > > > > > > (@RolesAllowed) > > > > > > > > > > > > > > based > > > > > > > > > > > > > > on either realm roles or the roles of one > > > > > > > > > > > > > > specific > > > > > > > > > > > > > > application. > > > > > > > > > > > > > > This > > > > > > > > > > > > > > is > > > > > > > > > > > > > > related to 1) too. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > 1) Sounds like something definitely worth > > > > > > > > > > > > > > > aiming > > > > > > > > > > > > > > > for. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen wrote: > > > > > > > > > > > > > > >> I just wanted to quickly list the additional > > > > > > > > > > > > > > >> work > > > > > > > > > > > > > > >> we > > > > > > > > > > > > > > >> discussed > > > > > > > > > > > > > > >> so > > > > > > > > > > > > > > >> everyone > > > > > > > > > > > > > > >> can think about it (in no particular order): > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with > > > > > > > > > > > > > > >> mapping > > > > > > > > > > > > > > >> of > > > > > > > > > > > > > > >> an > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > >> token > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > >> a KC token? For example an external token with > > > > > > > > > > > > > > >> attribute > > > > > > > > > > > > > > >> 'group' > > > > > > > > > > > > > > >> that > > > > > > > > > > > > > > >> contains 'sales' and 'manager' could be mapped > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > >> 'manager' > > > > > > > > > > > > > > >> role > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > >> 'sales app in a KC token. Could we use Drools? > > > > > > > > > > > > > > >> This > > > > > > > > > > > > > > >> could > > > > > > > > > > > > > > >> also > > > > > > > > > > > > > > >> be > > > > > > > > > > > > > > >> used > > > > > > > > > > > > > > >> in > > > > > > > > > > > > > > >> user federation to allow more complex mapping > > > > > > > > > > > > > > >> of > > > > > > > > > > > > > > >> roles/groups > > > > > > > > > > > > > > >> than > > > > > > > > > > > > > > >> a > > > > > > > > > > > > > > >> simple 1-1 > > > > > > > > > > > > > > >> 2) Retrieving tokens - if an application wants > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > >> retrieve > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > >> token (for example to view Facebook friends if > > > > > > > > > > > > > > >> user > > > > > > > > > > > > > > >> logged > > > > > > > > > > > > > > >> in > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > >> Facebook) > > > > > > > > > > > > > > >> 3) Configure scope - currently for social we > > > > > > > > > > > > > > >> only > > > > > > > > > > > > > > >> request > > > > > > > > > > > > > > >> a > > > > > > > > > > > > > > >> very > > > > > > > > > > > > > > >> limited > > > > > > > > > > > > > > >> scope (basic profile and email), to for > > > > > > > > > > > > > > >> example > > > > > > > > > > > > > > >> view > > > > > > > > > > > > > > >> Facebook > > > > > > > > > > > > > > >> friends > > > > > > > > > > > > > > >> we'd need to ask for that as well > > > > > > > > > > > > > > >> 4) Selecting provider - currently in social > > > > > > > > > > > > > > >> (and > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > >> first > > > > > > > > > > > > > > >> pass > > > > > > > > > > > > > > >> of > > > > > > > > > > > > > > >> brokering) we have an icon user has to select, > > > > > > > > > > > > > > >> but > > > > > > > > > > > > > > >> can > > > > > > > > > > > > > > >> we > > > > > > > > > > > > > > >> select > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > >> provider in a different way (for example ask > > > > > > > > > > > > > > >> user > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > >> email, > > > > > > > > > > > > > > >> and > > > > > > > > > > > > > > >> select > > > > > > > > > > > > > > >> based on email domain) > > > > > > > > > > > > > > >> 5) Gateway - don't create a KC token, but just > > > > > > > > > > > > > > >> forward > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > >> token > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> IMO 1) is a killer feature, as it would allow > > > > > > > > > > > > > > >> companies > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > >> add > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > >> users without having to modify their > > > > > > > > > > > > > > >> applications. > > > > > > > > > > > > > > >> Issue > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > >> 5) > > > > > > > > > > > > > > >> is > > > > > > > > > > > > > > >> that > > > > > > > > > > > > > > >> applications need to understand more than one > > > > > > > > > > > > > > >> token, > > > > > > > > > > > > > > >> which > > > > > > > > > > > > > > >> would > > > > > > > > > > > > > > >> require > > > > > > > > > > > > > > >> rewriting applications. > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> This work is also somewhat related to other > > > > > > > > > > > > > > >> authentication > > > > > > > > > > > > > > >> mechanisms > > > > > > > > > > > > > > >> (for > > > > > > > > > > > > > > >> example Kerberos ticket, LDAP and > > > > > > > > > > > > > > >> passwordless). > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> ----- Original Message ----- > > > > > > > > > > > > > > >>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 8:27:58 PM > > > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > >>> Identity > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > >>> Authentication > > > > > > > > > > > > > > >>> Broker > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > > > > > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 4:39:52 > > > > > > > > > > > > > > >>>> PM > > > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > >>>> Identity > > > > > > > > > > > > > > >>>> and > > > > > > > > > > > > > > >>>> Authentication > > > > > > > > > > > > > > >>>> Broker > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva > > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > >>>>> Hi, > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> Would like to start a discussion > > > > > > > > > > > > > > >>>>> about > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> enable > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > >>>>> Authentication Broker in order to > > > > > > > > > > > > > > >>>>> supported > > > > > > > > > > > > > > >>>>> Chained > > > > > > > > > > > > > > >>>>> Federation > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > >>>>> also Identity Federation. First of > > > > > > > > > > > > > > >>>>> all, > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > >>>>> background > > > > > > > > > > > > > > >>>>> about > > > > > > > > > > > > > > >>>>> what > > > > > > > > > > > > > > >>>>> this is all about. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> Currently KeyCloak provides two > > > > > > > > > > > > > > >>>>> basic > > > > > > > > > > > > > > >>>>> types > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > >>>>> (correct > > > > > > > > > > > > > > >>>>> me if I'm wrong, please): > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> 1) Local authentication (based > > > > > > > > > > > > > > >>>>> on > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > >>>>> credential > > > > > > > > > > > > > > >>>>> type > > > > > > > > > > > > > > >>>>> enabled > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> a realm) > > > > > > > > > > > > > > >>>>> 2) Social authentication > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> Local authentication is about > > > > > > > > > > > > > > >>>>> authenticating > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > > > >>>>> locally > > > > > > > > > > > > > > >>>>> using > > > > > > > > > > > > > > >>>>> KC's own identity store. Nothing > > > > > > > > > > > > > > >>>>> special > > > > > > > > > > > > > > >>>>> here. > > > > > > > > > > > > > > >>>>> And > > > > > > > > > > > > > > >>>>> Social > > > > > > > > > > > > > > >>>>> Authentication which allows users to > > > > > > > > > > > > > > >>>>> choose > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> Social > > > > > > > > > > > > > > >>>>> IdP > > > > > > > > > > > > > > >>>>> they > > > > > > > > > > > > > > >>>>> want > > > > > > > > > > > > > > >>>>> to authenticate with. In this case, > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> IdP > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > >>>>> always > > > > > > > > > > > > > > >>>>> one > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> built-in social providers supported > > > > > > > > > > > > > > >>>>> by > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > >>>>> Facebook, > > > > > > > > > > > > > > >>>>> Google, > > > > > > > > > > > > > > >>>>> Twitter, Github and so forth. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> When doing social, the user is > > > > > > > > > > > > > > >>>>> automatically > > > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > > > >>>>> in > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > >>>>> identity store after a successful > > > > > > > > > > > > > > >>>>> authentication. > > > > > > > > > > > > > > >>>>> The > > > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > > > >>>>> does > > > > > > > > > > > > > > >>>>> not > > > > > > > > > > > > > > >>>>> need to fill a registration form and > > > > > > > > > > > > > > >>>>> can > > > > > > > > > > > > > > >>>>> access > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > >>>>> very > > > > > > > > > > > > > > >>>>> quickly. During the provisioning > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > >>>>> basic > > > > > > > > > > > > > > >>>>> information > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > >>>>> retrieved > > > > > > > > > > > > > > >>>>> from the social provider such as > > > > > > > > > > > > > > >>>>> email, > > > > > > > > > > > > > > >>>>> firstname > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > > > >>>>> forth. > > > > > > > > > > > > > > >>>>> These > > > > > > > > > > > > > > >>>>> are very basic information, any > > > > > > > > > > > > > > >>>>> other > > > > > > > > > > > > > > >>>>> information > > > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > >>>>> those > > > > > > > > > > > > > > >>>>> related with authorization policies > > > > > > > > > > > > > > >>>>> - > > > > > > > > > > > > > > >>>>> eg.: > > > > > > > > > > > > > > >>>>> roles > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > >>>>> groups > > > > > > > > > > > > > > >>>>> - > > > > > > > > > > > > > > >>>>> must > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > >>>>> defined later via KC's admin > > > > > > > > > > > > > > >>>>> console. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> Another important characteristic of > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> application receives a KC token and > > > > > > > > > > > > > > >>>>> not > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > >>>>> was > > > > > > > > > > > > > > >>>>> issued by > > > > > > > > > > > > > > >>>>> the social IdP during the > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > >>>>> process. > > > > > > > > > > > > > > >>>>> If > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > >>>>> wants to consume resources from the > > > > > > > > > > > > > > >>>>> resource > > > > > > > > > > > > > > >>>>> provider > > > > > > > > > > > > > > >>>>> he > > > > > > > > > > > > > > >>>>> was > > > > > > > > > > > > > > >>>>> authenticated it must obtain the > > > > > > > > > > > > > > >>>>> access > > > > > > > > > > > > > > >>>>> token(again) > > > > > > > > > > > > > > >>>>> by > > > > > > > > > > > > > > >>>>> itself > > > > > > > > > > > > > > >>>>> prior > > > > > > > > > > > > > > >>>>> to invoke the resource provider API. > > > > > > > > > > > > > > >>>>> Assuming > > > > > > > > > > > > > > >>>>> all > > > > > > > > > > > > > > >>>>> those > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > >>>>> providers are based on oAuth 1.0 or > > > > > > > > > > > > > > >>>>> 2.0. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> That said, the Authentication Broker > > > > > > > > > > > > > > >>>>> functionality > > > > > > > > > > > > > > >>>>> aims > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> cover > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> same use cases but with a lot of > > > > > > > > > > > > > > >>>>> more > > > > > > > > > > > > > > >>>>> flexibility > > > > > > > > > > > > > > >>>>> on > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > >>>>> you > > > > > > > > > > > > > > >>>>> setup > > > > > > > > > > > > > > >>>>> identity providers(not only social > > > > > > > > > > > > > > >>>>> ones) > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > > > >>>>> federation > > > > > > > > > > > > > > >>>>> protocols they may support such as > > > > > > > > > > > > > > >>>>> SAML, > > > > > > > > > > > > > > >>>>> OpenID, > > > > > > > > > > > > > > >>>>> oAuth > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > > > >>>>> forth. > > > > > > > > > > > > > > >>>>> This is useful when an enterprise is > > > > > > > > > > > > > > >>>>> providing > > > > > > > > > > > > > > >>>>> services > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > > > >>>>> customers(IdP) and does not want to > > > > > > > > > > > > > > >>>>> manage > > > > > > > > > > > > > > >>>>> many > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> many > > > > > > > > > > > > > > >>>>> relationships. When using a broker, > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > >>>>> steps > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > >>>>> pretty much the same when you are > > > > > > > > > > > > > > >>>>> using > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > >>>>> authentication, > > > > > > > > > > > > > > >>>>> with > > > > > > > > > > > > > > >>>>> important differences on how you > > > > > > > > > > > > > > >>>>> support > > > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > > > >>>>> identity > > > > > > > > > > > > > > >>>>> providers, different federation > > > > > > > > > > > > > > >>>>> protocols, > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > > > >>>>> and how claims and attributes are > > > > > > > > > > > > > > >>>>> resolved. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> The brokering functionality can be > > > > > > > > > > > > > > >>>>> done > > > > > > > > > > > > > > >>>>> in > > > > > > > > > > > > > > >>>>> two > > > > > > > > > > > > > > >>>>> ways > > > > > > > > > > > > > > >>>>> depending > > > > > > > > > > > > > > >>>>> if > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> broker service is acting as a > > > > > > > > > > > > > > >>>>> gateway > > > > > > > > > > > > > > >>>>> or > > > > > > > > > > > > > > >>>>> not. > > > > > > > > > > > > > > >>>>> When > > > > > > > > > > > > > > >>>>> acting > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > > > >>>>> gateway, the broker will respond to > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> same > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > >>>>> issued by the trusted identity > > > > > > > > > > > > > > >>>>> provider. > > > > > > > > > > > > > > >>>>> For > > > > > > > > > > > > > > >>>>> instance, > > > > > > > > > > > > > > >>>>> if > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > > > >>>>> selects a SAML IdP to authenticate > > > > > > > > > > > > > > >>>>> with, > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > >>>>> will > > > > > > > > > > > > > > >>>>> receive > > > > > > > > > > > > > > >>>>> a SAML Response. In this case, the > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > >>>>> must > > > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > >>>>> prepared > > > > > > > > > > > > > > >>>>> to handle a specific federation > > > > > > > > > > > > > > >>>>> protocol. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> However, the broker service can also > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > >>>>> used > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> completely > > > > > > > > > > > > > > >>>>> abstract > > > > > > > > > > > > > > >>>>> from the application the protocol > > > > > > > > > > > > > > >>>>> used > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > >>>>> user. > > > > > > > > > > > > > > >>>>> In > > > > > > > > > > > > > > >>>>> this case, the application will just > > > > > > > > > > > > > > >>>>> receive > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > >>>>> ordinary > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > >>>>> after a successful authentication. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> In both cases, the broker acts as an > > > > > > > > > > > > > > >>>>> intermediary > > > > > > > > > > > > > > >>>>> where > > > > > > > > > > > > > > >>>>> specific > > > > > > > > > > > > > > >>>>> security policies can be applied > > > > > > > > > > > > > > >>>>> when > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > >>>>> try > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > > > >>>>> themselves against a 3rd party IdP. > > > > > > > > > > > > > > >>>>> That > > > > > > > > > > > > > > >>>>> brings > > > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > > > >>>>> lot > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > >>>>> value > > > > > > > > > > > > > > >>>>> when > > > > > > > > > > > > > > >>>>> you think about auditing, > > > > > > > > > > > > > > >>>>> authorization > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > > > >>>>> when federation of identities is > > > > > > > > > > > > > > >>>>> needed. > > > > > > > > > > > > > > >>>>> This > > > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > > > >>>>> allows > > > > > > > > > > > > > > >>>>> existing > > > > > > > > > > > > > > >>>>> security infrastructures (eg.: > > > > > > > > > > > > > > >>>>> SAML-based > > > > > > > > > > > > > > >>>>> infrastructures) > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> benefit > > > > > > > > > > > > > > >>>>> from KC's support for cloud, rest > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > >>>>> mobile > > > > > > > > > > > > > > >>>>> use > > > > > > > > > > > > > > >>>>> cases. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>>> I think this is enough to start a > > > > > > > > > > > > > > >>>>> discussion. > > > > > > > > > > > > > > >>>>> I've > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > >>>>> initial > > > > > > > > > > > > > > >>>>> discussion with Stian about all that > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > >>>>> we > > > > > > > > > > > > > > >>>>> agreed > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > >>>>> abstract > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > >>>>> protocol from applications should be > > > > > > > > > > > > > > >>>>> prioritized. > > > > > > > > > > > > > > >>>>> The > > > > > > > > > > > > > > >>>>> main > > > > > > > > > > > > > > >>>>> reason is > > > > > > > > > > > > > > >>>>> that it makes life easier for > > > > > > > > > > > > > > >>>>> applications > > > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > > > >>>>> they > > > > > > > > > > > > > > >>>>> only > > > > > > > > > > > > > > >>>>> need > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > >>>>> know > > > > > > > > > > > > > > >>>>> about KC tokens and nothing else. > > > > > > > > > > > > > > >>>>> However > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > >>>>> brings > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > >>>>> new > > > > > > > > > > > > > > >>>>> requirements around user > > > > > > > > > > > > > > >>>>> provisioning > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > >>>>> claim/attribute > > > > > > > > > > > > > > >>>>> resolution > > > > > > > > > > > > > > >>>>> or mapping. But that would be > > > > > > > > > > > > > > >>>>> another > > > > > > > > > > > > > > >>>>> thread. > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> Can you elaborate on "abstract the protocol > > > > > > > > > > > > > > >>>> from > > > > > > > > > > > > > > >>>> applications"? > > > > > > > > > > > > > > >>>> Not > > > > > > > > > > > > > > >>>> sure what you mean by that. IDP federation > > > > > > > > > > > > > > >>>> should > > > > > > > > > > > > > > >>>> be > > > > > > > > > > > > > > >>>> configured > > > > > > > > > > > > > > >>>> at > > > > > > > > > > > > > > >>>> the > > > > > > > > > > > > > > >>>> realm level and really has nothing to do > > > > > > > > > > > > > > >>>> with > > > > > > > > > > > > > > >>>> applications. > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> I'm really happy that somebody is doing > > > > > > > > > > > > > > >>>> this. > > > > > > > > > > > > > > >>>> We're > > > > > > > > > > > > > > >>>> getting > > > > > > > > > > > > > > >>>> a > > > > > > > > > > > > > > >>>> real > > > > > > > > > > > > > > >>>> impressive feature set! > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> Sure. What I meant was that the application > > > > > > > > > > > > > > >>> only > > > > > > > > > > > > > > >>> knows > > > > > > > > > > > > > > >>> about > > > > > > > > > > > > > > >>> KC > > > > > > > > > > > > > > >>> tokens > > > > > > > > > > > > > > >>> nothing else. It will always receive a KC > > > > > > > > > > > > > > >>> token > > > > > > > > > > > > > > >>> regardless > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > >>> protocol > > > > > > > > > > > > > > >>> used > > > > > > > > > > > > > > >>> to authenticate the user against a 3rd party > > > > > > > > > > > > > > >>> IdP > > > > > > > > > > > > > > >>> (saml, > > > > > > > > > > > > > > >>> oidc, > > > > > > > > > > > > > > >>> whatever). > > > > > > > > > > > > > > >>> The > > > > > > > > > > > > > > >>> example I gave was about an user trying to > > > > > > > > > > > > > > >>> authenticate > > > > > > > > > > > > > > >>> against > > > > > > > > > > > > > > >>> a > > > > > > > > > > > > > > >>> SAML > > > > > > > > > > > > > > >>> IdP. > > > > > > > > > > > > > > >>> In this case, after a successful > > > > > > > > > > > > > > >>> authentication > > > > > > > > > > > > > > >>> on > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > >>> IdP, > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > >>> IdP > > > > > > > > > > > > > > >>> will > > > > > > > > > > > > > > >>> issue a token to KC. Then KC will validate > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > >>> token, > > > > > > > > > > > > > > >>> perform > > > > > > > > > > > > > > >>> trust > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > >>> security checks, do user provisioning and > > > > > > > > > > > > > > >>> attribute/claim > > > > > > > > > > > > > > >>> resolution > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > >>> finally issue a KC token and redirect the > > > > > > > > > > > > > > >>> user > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > >>> application. > > > > > > > > > > > > > > >>> If > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > >>> app is configured to use openid in KC then it > > > > > > > > > > > > > > >>> will > > > > > > > > > > > > > > >>> receive > > > > > > > > > > > > > > >>> a > > > > > > > > > > > > > > >>> openid > > > > > > > > > > > > > > >>> token > > > > > > > > > > > > > > >>> from KC, not saml ... > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> The other scenario is pretty much the same. > > > > > > > > > > > > > > >>> The > > > > > > > > > > > > > > >>> difference > > > > > > > > > > > > > > >>> is > > > > > > > > > > > > > > >>> that > > > > > > > > > > > > > > >>> KC > > > > > > > > > > > > > > >>> will > > > > > > > > > > > > > > >>> not issue its own token but just replay the > > > > > > > > > > > > > > >>> token > > > > > > > > > > > > > > >>> issued > > > > > > > > > > > > > > >>> by > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > >>> 3rd > > > > > > > > > > > > > > >>> party > > > > > > > > > > > > > > >>> IdP to the service provider. > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> I agree that this config goes at the realm > > > > > > > > > > > > > > >>> level. > > > > > > > > > > > > > > >>> For > > > > > > > > > > > > > > >>> instance, > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > >>> create > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > >>> enable providers for being used. However, I > > > > > > > > > > > > > > >>> think > > > > > > > > > > > > > > >>> we > > > > > > > > > > > > > > >>> would > > > > > > > > > > > > > > >>> need > > > > > > > > > > > > > > >>> some > > > > > > > > > > > > > > >>> specific configuration for applications as > > > > > > > > > > > > > > >>> well. > > > > > > > > > > > > > > >>> Specially > > > > > > > > > > > > > > >>> when > > > > > > > > > > > > > > >>> defining > > > > > > > > > > > > > > >>> default roles, mapping attributes. Another > > > > > > > > > > > > > > >>> example > > > > > > > > > > > > > > >>> of > > > > > > > > > > > > > > >>> application > > > > > > > > > > > > > > >>> config > > > > > > > > > > > > > > >>> is > > > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want to > > > > > > > > > > > > > > >>> define > > > > > > > > > > > > > > >>> scopes > > > > > > > > > > > > > > >>> per-application. > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>>> -- > > > > > > > > > > > > > > >>>> Bill Burke > > > > > > > > > > > > > > >>>> JBoss, a division of Red Hat > > > > > > > > > > > > > > >>>> http://bill.burkecentral.com > > > > > > > > > > > > > > >>>> _______________________________________________ > > > > > > > > > > > > > > >>>> keycloak-dev mailing list > > > > > > > > > > > > > > >>>> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > >>> _______________________________________________ > > > > > > > > > > > > > > >>> keycloak-dev mailing list > > > > > > > > > > > > > > >>> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >> _______________________________________________ > > > > > > > > > > > > > > >> keycloak-dev mailing list > > > > > > > > > > > > > > >> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Bill Burke > > > > > > > > > > > > > > JBoss, a division of Red Hat > > > > > > > > > > > > > > http://bill.burkecentral.com > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > keycloak-dev mailing list > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, 5 December, 2014 3:29:08 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, December 5, 2014 12:23:53 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Friday, 5 December, 2014 3:15:42 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Friday, December 5, 2014 12:07:37 PM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Friday, 5 December, 2014 2:57:46 PM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > ----- Original Message ----- > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Friday, December 5, 2014 11:43:32 AM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Friday, 5 December, 2014 2:36:14 PM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Friday, December 5, 2014 10:59:08 AM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > Another related thing. We've had a few people ask to be able to > > > > > > > login > > > > > > > to > > > > > > > Keycloak on mobiles using the native social login mechanism. > > > > > > > > > > > > > > I think the best way to do that is to use the direct grant api > > > > > > > and > > > > > > > make > > > > > > > it > > > > > > > possible to call that endpoint passing a IdP id and a token > > > > > > > instead > > > > > > > of > > > > > > > username and password. > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > The broker endpoint expects the idp id in order to start the > > > > > > authentication > > > > > > process. Today, the endpoint also expects KCs authorization code > > > > > > in > > > > > > order > > > > > > to > > > > > > validate requests from clients and use it as a state to validate > > > > > > responses > > > > > > from the trusted idps. > > > > > > > > > > > > This authorization code is a blocker for this use case, given > > > > > > that > > > > > > mobile > > > > > > don't have this code and just want to start the authentication. > > > > > > > > > > > > A possible solution would be to change the broker to also accept > > > > > > a > > > > > > client_id > > > > > > to reference the mobile app and perform some validations based on > > > > > > that. > > > > > > Something like that: > > > > > > > > > > > > 1) Mobile displays a Facebook button > > > > > > 2) User clicks the button and mobile sends a request to KC Broker > > > > > > with > > > > > > the > > > > > > idp id and his client_id. > > > > > > 3) KC Broker checks if the client_id is valid and creates a > > > > > > temporary > > > > > > authorization code. > > > > > > 4) KC Broker redirect mobile to the chosen IdP to perform > > > > > > authentication. > > > > > > 5) KC Broker receives a response from the IdP, generate its own > > > > > > token > > > > > > and > > > > > > send it back to mobile > > > > > > > > > > > > Makes sense ? > > > > > > > > > > No that's not the flow I had in mind. Basically the mobile app > > > > > authenticates > > > > > with Facebook through the native mechanisms. The app then has an > > > > > access > > > > > token, which it would send to Keycloak on the direct grant api to > > > > > obtain > > > > > a > > > > > Keycloak token. > > > > > > > > Ahh, now I get what you mean :) > > > > > > > > Yes, what you said is enough. Then we just need to validate the > > > > access > > > > token > > > > (eg.: using a tokeninfo endpoint). > > > > > > > > But I think we can also consider that use case I mentioned. You may > > > > want > > > > to > > > > login without forcing the user to redirect to KC login page. > > > > > > We could just add a query param to the login url that lets you pick the > > > IdP > > > to use by alias? > > > > > > For example auth/.../login?client_id=...&auth_method=google > > > > Yes, just like my previously example, we need the client_id. The idp > > id/alias > > is already there. > > Sure, was just saying it should be the same URL as the regular login page, > but with one extra param to specify the IdP. > > > > > Btw, regarding SAML. SAML does not provide a "validation" endpoint like > > oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the > > specs for that. What can be done here is validate SAML assertions against > > a > > WS-Trust STS. Or just trust the assertion based on the signature and > > others > > standards info along it. > > > > We can also take a closer look at the oAuth2 SAML bearer token profile > > and > > see if it helps. > > If we could have it for social and OpenID Connect providers for now that'd > be > good. Deal. I'll do that. What about that use case I mentioned ? The one about mobile asking to broker (not previously issued access_token) an identity provider ?

> > > > > > > > > > > > > > > > > > > > Same for other identity providers, the assumption is the app has an > > > > > out > > > > > of > > > > > bounds mechanism to obtain an access token, which is then sent to > > > > > Keycloak > > > > > over the direct grant api. > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > Sent: Friday, 5 December, 2014 1:45:24 PM > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > Authentication > > > > > > > > Broker > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > Sent: Friday, December 5, 2014 10:22:10 AM > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > Authentication > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > Looks good. I reckon we can combine the two pages. What > > > > > > > > > about > > > > > > > > > if > > > > > > > > > the > > > > > > > > > 'Add > > > > > > > > > provider' drop-down is: > > > > > > > > > > > > > > > > > > OpenID > > > > > > > > > SAML > > > > > > > > > ------ > > > > > > > > > Google > > > > > > > > > GitHub > > > > > > > > > Facebook > > > > > > > > > Twitter > > > > > > > > > > > > > > > > > > Let's drop social on/off and instead have a enable/disable > > > > > > > > > button > > > > > > > > > on > > > > > > > > > each > > > > > > > > > provider. > > > > > > > > > > > > > > > > Sure. > > > > > > > > > > > > > > > > > > > > > > > > > > Also, would be nice if users could set a name or alias for > > > > > > > > > a > > > > > > > > > provider > > > > > > > > > instance. This would make the callback url easier to use > > > > > > > > > (instead > > > > > > > > > of > > > > > > > > > callback/<UUID> it's callback/<alias>). The user federation > > > > > > > > > providers > > > > > > > > > have > > > > > > > > > this. > > > > > > > > > > > > > > > > One of my first tries was using an alias, just like that. But > > > > > > > > I > > > > > > > > preferred > > > > > > > > using the UUID and make the configuration more easier. Beside > > > > > > > > that, > > > > > > > > the > > > > > > > > callback url is just a copy and paste, so I think an alias > > > > > > > > would > > > > > > > > not > > > > > > > > bring > > > > > > > > so much usability, but add one more step when configuring > > > > > > > > providers. > > > > > > > > > > > > > > > > However, if this is an usability requirement for KC I can > > > > > > > > change > > > > > > > > that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > Authentication > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > In one of our last discussions, you suggested to leave > > > > > > > > > > Social > > > > > > > > > > as > > > > > > > > > > it > > > > > > > > > > is. > > > > > > > > > > Although IMO I think we can have a single place to manage > > > > > > > > > > both > > > > > > > > > > social > > > > > > > > > > and > > > > > > > > > > user-defined identity providers. Social ones are just > > > > > > > > > > OOTB > > > > > > > > > > and > > > > > > > > > > pre-configured identity providers now. > > > > > > > > > > > > > > > > > > > > That said, today I'm using separated tabs for social and > > > > > > > > > > user-defined. > > > > > > > > > > Please, take a look at [1] for more details on how the UI > > > > > > > > > > looks > > > > > > > > > > like. > > > > > > > > > > > > > > > > > > > > I've changed social UI a bit in order to provide a > > > > > > > > > > specific > > > > > > > > > > page > > > > > > > > > > for > > > > > > > > > > create/update. I've also added a "Show Secret" link to > > > > > > > > > > display > > > > > > > > > > the > > > > > > > > > > client_secret in clear text if user wants to. > > > > > > > > > > > > > > > > > > > > Beside the enable/disable button, I think another good > > > > > > > > > > thing > > > > > > > > > > to > > > > > > > > > > do > > > > > > > > > > is > > > > > > > > > > specify > > > > > > > > > > a default role(s) for each provider. That can be useful > > > > > > > > > > if > > > > > > > > > > applications > > > > > > > > > > want > > > > > > > > > > to perform any kind of authorization based on the > > > > > > > > > > identity > > > > > > > > > > provider > > > > > > > > > > or > > > > > > > > > > authentication method used to authenticate an user (eg.: > > > > > > > > > > useful > > > > > > > > > > for > > > > > > > > > > adaptative or multi-level access control). We can also > > > > > > > > > > use > > > > > > > > > > the > > > > > > > > > > "amr" > > > > > > > > > > claim > > > > > > > > > > in the ID Token, which seems KC is not considering at > > > > > > > > > > all. > > > > > > > > > > The > > > > > > > > > > latter > > > > > > > > > > is > > > > > > > > > > an > > > > > > > > > > important thing to think of, regardless this broker work > > > > > > > > > > I'm > > > > > > > > > > doing. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sha... > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > Authentication > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > Having a separate enable/disable for each provider would > > > > > > > > > > be > > > > > > > > > > good. > > > > > > > > > > If > > > > > > > > > > you're > > > > > > > > > > leaving the social tab as is and adding a separate tab > > > > > > > > > > for > > > > > > > > > > configuring > > > > > > > > > > brokered idp's then we should leave the social > > > > > > > > > > enable/disable > > > > > > > > > > button, > > > > > > > > > > otherwise it depends how it'll look like in the end. > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > Authentication > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Social has a button to enable/disable it. I'm > > > > > > > > > > > wondering > > > > > > > > > > > what > > > > > > > > > > > to > > > > > > > > > > > do > > > > > > > > > > > with > > > > > > > > > > > the brokered identity providers. Shall we add a > > > > > > > > > > > similar > > > > > > > > > > > flag > > > > > > > > > > > for > > > > > > > > > > > that > > > > > > > > > > > ? > > > > > > > > > > > > > > > > > > > > > > I was also wondering if the best would be a flag in > > > > > > > > > > > a > > > > > > > > > > > per > > > > > > > > > > > provider > > > > > > > > > > > basis. > > > > > > > > > > > So we can disable/enable a specific provider (social > > > > > > > > > > > or > > > > > > > > > > > brokered), > > > > > > > > > > > instead of doing that for all. > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > Pedro Igor > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > Authentication > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > Authentication > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > I'll go for it then. Will remove the icon url from > > > > > > > > > > > > > the > > > > > > > > > > > > > model > > > > > > > > > > > > > and > > > > > > > > > > > > > leave > > > > > > > > > > > > > that > > > > > > > > > > > > > for users if they want to provide icons for their > > > > > > > > > > > > > identity > > > > > > > > > > > > > providers. > > > > > > > > > > > > > > > > > > > > > > > > > > My point is that icons can be usually served by the > > > > > > > > > > > > > same > > > > > > > > > > > > > server/application > > > > > > > > > > > > > or proxy, so download images are not such a big > > > > > > > > > > > > > deal. > > > > > > > > > > > > > Also, > > > > > > > > > > > > > the > > > > > > > > > > > > > icon > > > > > > > > > > > > > url > > > > > > > > > > > > > is > > > > > > > > > > > > > part of the freemarker model and people can do what > > > > > > > > > > > > > ever > > > > > > > > > > > > > they > > > > > > > > > > > > > want > > > > > > > > > > > > > with > > > > > > > > > > > > > it. > > > > > > > > > > > > > What I think will also help in your future plans. > > > > > > > > > > > > > > > > > > > > > > > > I'm not following. Are you saying that if a named > > > > > > > > > > > > image > > > > > > > > > > > > 'my-provider.png' > > > > > > > > > > > > is > > > > > > > > > > > > loaded from a theme, then you can override it in > > > > > > > > > > > > another > > > > > > > > > > > > theme? > > > > > > > > > > > > > > > > > > > > > > > > If so, that's basically the same as having a css > > > > > > > > > > > > class > > > > > > > > > > > > 'my-provider' > > > > > > > > > > > > in > > > > > > > > > > > > a > > > > > > > > > > > > theme. With the exception that with an image you end > > > > > > > > > > > > up > > > > > > > > > > > > with > > > > > > > > > > > > having > > > > > > > > > > > > to > > > > > > > > > > > > require a image per provider per theme per language, > > > > > > > > > > > > which > > > > > > > > > > > > could > > > > > > > > > > > > be > > > > > > > > > > > > a > > > > > > > > > > > > lot > > > > > > > > > > > > of > > > > > > > > > > > > images for a single provider. Also, buttons for > > > > > > > > > > > > accessibility > > > > > > > > > > > > should > > > > > > > > > > > > be > > > > > > > > > > > > defined with text and css, not images that can't be > > > > > > > > > > > > interpreted. > > > > > > > > > > > > You > > > > > > > > > > > > also > > > > > > > > > > > > still need to modify the theme, so I don't see any > > > > > > > > > > > > benefits. > > > > > > > > > > > > > > > > > > > > > > You are right. Having a icon url per provider does not > > > > > > > > > > > makes > > > > > > > > > > > sense > > > > > > > > > > > if > > > > > > > > > > > there > > > > > > > > > > > are requirements to change images accordingly to a > > > > > > > > > > > theme > > > > > > > > > > > or > > > > > > > > > > > language. > > > > > > > > > > > CSS > > > > > > > > > > > makes life easier. > > > > > > > > > > > > > > > > > > > > > > Will remove that property from the model. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > > > and > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > Users can now specify a Icon Url to be rendered > > > > > > > > > > > > > > on > > > > > > > > > > > > > > the > > > > > > > > > > > > > > login > > > > > > > > > > > > > > page > > > > > > > > > > > > > > when > > > > > > > > > > > > > > social > > > > > > > > > > > > > > or any other identity provider is configured. So > > > > > > > > > > > > > > we > > > > > > > > > > > > > > just > > > > > > > > > > > > > > load > > > > > > > > > > > > > > the > > > > > > > > > > > > > > image > > > > > > > > > > > > > > the > > > > > > > > > > > > > > url entered by the user. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Are you saying that users should change the theme > > > > > > > > > > > > > > or > > > > > > > > > > > > > > customize > > > > > > > > > > > > > > css > > > > > > > > > > > > > > if > > > > > > > > > > > > > > they > > > > > > > > > > > > > > only want to change an icon for a provider ? > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, there's many issues with having a icon url: > > > > > > > > > > > > > > > > > > > > > > > > > > * Won't work for internationalization - we don't > > > > > > > > > > > > > have > > > > > > > > > > > > > this > > > > > > > > > > > > > now, > > > > > > > > > > > > > but > > > > > > > > > > > > > we > > > > > > > > > > > > > will > > > > > > > > > > > > > * Image is not a good button - CSS is much better > > > > > > > > > > > > > * Doesn't support themes - we allow users to switch > > > > > > > > > > > > > l&f > > > > > > > > > > > > > by > > > > > > > > > > > > > switching > > > > > > > > > > > > > themes, > > > > > > > > > > > > > but that won't work for a icon url. In the future > > > > > > > > > > > > > we > > > > > > > > > > > > > may > > > > > > > > > > > > > also > > > > > > > > > > > > > support > > > > > > > > > > > > > multiple themes per-realm, for example to depending > > > > > > > > > > > > > on > > > > > > > > > > > > > the > > > > > > > > > > > > > devices > > > > > > > > > > > > > (one > > > > > > > > > > > > > theme for mobiles, one for desktops, etc) > > > > > > > > > > > > > * Requires the URL to be hosted somewhere - why > > > > > > > > > > > > > require > > > > > > > > > > > > > a > > > > > > > > > > > > > separate > > > > > > > > > > > > > call > > > > > > > > > > > > > to > > > > > > > > > > > > > download an image (to a separate server maybe) if > > > > > > > > > > > > > it > > > > > > > > > > > > > can > > > > > > > > > > > > > simply > > > > > > > > > > > > > be > > > > > > > > > > > > > defined > > > > > > > > > > > > > in a single CSS file? > > > > > > > > > > > > > > > > > > > > > > > > > > Rather than add additional places to define look > > > > > > > > > > > > > and > > > > > > > > > > > > > feel > > > > > > > > > > > > > components > > > > > > > > > > > > > we > > > > > > > > > > > > > should in the future make it easier to > > > > > > > > > > > > > add/customize > > > > > > > > > > > > > themes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > > > and > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > All look and feel related things including images > > > > > > > > > > > > > > and > > > > > > > > > > > > > > stylesheets > > > > > > > > > > > > > > should > > > > > > > > > > > > > > be > > > > > > > > > > > > > > part of themes. This is to allow customizing them > > > > > > > > > > > > > > in > > > > > > > > > > > > > > the > > > > > > > > > > > > > > theme. > > > > > > > > > > > > > > Also, > > > > > > > > > > > > > > an > > > > > > > > > > > > > > image is not the correct way to render a button, > > > > > > > > > > > > > > it > > > > > > > > > > > > > > should > > > > > > > > > > > > > > be > > > > > > > > > > > > > > defined > > > > > > > > > > > > > > in > > > > > > > > > > > > > > CSS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You shouldn't have icon images for social > > > > > > > > > > > > > > > providers. > > > > > > > > > > > > > > > They > > > > > > > > > > > > > > > should > > > > > > > > > > > > > > > be > > > > > > > > > > > > > > > specified > > > > > > > > > > > > > > > as part of the theme in CSS as is now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 PM > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > Identity > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anyone know where I can get the icons > > > > > > > > > > > > > > > > images > > > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > social > > > > > > > > > > > > > > > > providers > > > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > > > It > > > > > > > > > > > > > > > > seems zocial defines them encoded in some > > > > > > > > > > > > > > > > way > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > CSS. > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > need > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > provide default images if user does not > > > > > > > > > > > > > > > > specify > > > > > > > > > > > > > > > > their > > > > > > > > > > > > > > > > own. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or is still possible to use zocial ones ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 PM > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > Identity > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've done some initial work covering both > > > > > > > > > > > > > > > > persistence > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > brokering. > > > > > > > > > > > > > > > > No > > > > > > > > > > > > > > > > UI, yet. I'm focused on the model, rest > > > > > > > > > > > > > > > > api > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > brokering > > > > > > > > > > > > > > > > functionality > > > > > > > > > > > > > > > > for now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What I have is enough to decide if we are > > > > > > > > > > > > > > > > aligned > > > > > > > > > > > > > > > > about > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > functionality. So you can understand how > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > model > > > > > > > > > > > > > > > > (and > > > > > > > > > > > > > > > > persistence), > > > > > > > > > > > > > > > > rest api and brokering functionality looks > > > > > > > > > > > > > > > > like. > > > > > > > > > > > > > > > > Can > > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > schedule > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > meeting ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Btw, my branch is here [1]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > Pedro Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > To: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 PM > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > Identity > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Currently adapters can only make authz > > > > > > > > > > > > > > > > decisions > > > > > > > > > > > > > > > > (@RolesAllowed) > > > > > > > > > > > > > > > > based > > > > > > > > > > > > > > > > on either realm roles or the roles of one > > > > > > > > > > > > > > > > specific > > > > > > > > > > > > > > > > application. > > > > > > > > > > > > > > > > This > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > related to 1) too. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Bolesław Dawidowicz > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > 1) Sounds like something definitely worth > > > > > > > > > > > > > > > > > aiming > > > > > > > > > > > > > > > > > for. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian Thorgersen > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > >> I just wanted to quickly list the > > > > > > > > > > > > > > > > >> additional > > > > > > > > > > > > > > > > >> work > > > > > > > > > > > > > > > > >> we > > > > > > > > > > > > > > > > >> discussed > > > > > > > > > > > > > > > > >> so > > > > > > > > > > > > > > > > >> everyone > > > > > > > > > > > > > > > > >> can think about it (in no particular > > > > > > > > > > > > > > > > >> order): > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal with > > > > > > > > > > > > > > > > >> mapping > > > > > > > > > > > > > > > > >> of > > > > > > > > > > > > > > > > >> an > > > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > > > >> token > > > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > > > >> a KC token? For example an external token > > > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > > > >> attribute > > > > > > > > > > > > > > > > >> 'group' > > > > > > > > > > > > > > > > >> that > > > > > > > > > > > > > > > > >> contains 'sales' and 'manager' could be > > > > > > > > > > > > > > > > >> mapped > > > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > > > >> 'manager' > > > > > > > > > > > > > > > > >> role > > > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > > > >> 'sales app in a KC token. Could we use > > > > > > > > > > > > > > > > >> Drools? > > > > > > > > > > > > > > > > >> This > > > > > > > > > > > > > > > > >> could > > > > > > > > > > > > > > > > >> also > > > > > > > > > > > > > > > > >> be > > > > > > > > > > > > > > > > >> used > > > > > > > > > > > > > > > > >> in > > > > > > > > > > > > > > > > >> user federation to allow more complex > > > > > > > > > > > > > > > > >> mapping > > > > > > > > > > > > > > > > >> of > > > > > > > > > > > > > > > > >> roles/groups > > > > > > > > > > > > > > > > >> than > > > > > > > > > > > > > > > > >> a > > > > > > > > > > > > > > > > >> simple 1-1 > > > > > > > > > > > > > > > > >> 2) Retrieving tokens - if an application > > > > > > > > > > > > > > > > >> wants > > > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > > > >> retrieve > > > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > > > >> token (for example to view Facebook > > > > > > > > > > > > > > > > >> friends > > > > > > > > > > > > > > > > >> if > > > > > > > > > > > > > > > > >> user > > > > > > > > > > > > > > > > >> logged > > > > > > > > > > > > > > > > >> in > > > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > > > >> Facebook) > > > > > > > > > > > > > > > > >> 3) Configure scope - currently for social > > > > > > > > > > > > > > > > >> we > > > > > > > > > > > > > > > > >> only > > > > > > > > > > > > > > > > >> request > > > > > > > > > > > > > > > > >> a > > > > > > > > > > > > > > > > >> very > > > > > > > > > > > > > > > > >> limited > > > > > > > > > > > > > > > > >> scope (basic profile and email), to for > > > > > > > > > > > > > > > > >> example > > > > > > > > > > > > > > > > >> view > > > > > > > > > > > > > > > > >> Facebook > > > > > > > > > > > > > > > > >> friends > > > > > > > > > > > > > > > > >> we'd need to ask for that as well > > > > > > > > > > > > > > > > >> 4) Selecting provider - currently in > > > > > > > > > > > > > > > > >> social > > > > > > > > > > > > > > > > >> (and > > > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > > > >> first > > > > > > > > > > > > > > > > >> pass > > > > > > > > > > > > > > > > >> of > > > > > > > > > > > > > > > > >> brokering) we have an icon user has to > > > > > > > > > > > > > > > > >> select, > > > > > > > > > > > > > > > > >> but > > > > > > > > > > > > > > > > >> can > > > > > > > > > > > > > > > > >> we > > > > > > > > > > > > > > > > >> select > > > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > >> provider in a different way (for example > > > > > > > > > > > > > > > > >> ask > > > > > > > > > > > > > > > > >> user > > > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > > > >> email, > > > > > > > > > > > > > > > > >> and > > > > > > > > > > > > > > > > >> select > > > > > > > > > > > > > > > > >> based on email domain) > > > > > > > > > > > > > > > > >> 5) Gateway - don't create a KC token, but > > > > > > > > > > > > > > > > >> just > > > > > > > > > > > > > > > > >> forward > > > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > > > >> token > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> IMO 1) is a killer feature, as it would > > > > > > > > > > > > > > > > >> allow > > > > > > > > > > > > > > > > >> companies > > > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > > > >> add > > > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > > > >> users without having to modify their > > > > > > > > > > > > > > > > >> applications. > > > > > > > > > > > > > > > > >> Issue > > > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > > > >> 5) > > > > > > > > > > > > > > > > >> is > > > > > > > > > > > > > > > > >> that > > > > > > > > > > > > > > > > >> applications need to understand more than > > > > > > > > > > > > > > > > >> one > > > > > > > > > > > > > > > > >> token, > > > > > > > > > > > > > > > > >> which > > > > > > > > > > > > > > > > >> would > > > > > > > > > > > > > > > > >> require > > > > > > > > > > > > > > > > >> rewriting applications. > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> This work is also somewhat related to > > > > > > > > > > > > > > > > >> other > > > > > > > > > > > > > > > > >> authentication > > > > > > > > > > > > > > > > >> mechanisms > > > > > > > > > > > > > > > > >> (for > > > > > > > > > > > > > > > > >> example Kerberos ticket, LDAP and > > > > > > > > > > > > > > > > >> passwordless). > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> ----- Original Message ----- > > > > > > > > > > > > > > > > >>> From: "Pedro Igor Silva" > > > > > > > > > > > > > > > > >>> <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 > > > > > > > > > > > > > > > > >>> 8:27:58 > > > > > > > > > > > > > > > > >>> PM > > > > > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > >>> Identity > > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > > >>> Authentication > > > > > > > > > > > > > > > > >>> Broker > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > > > > > > > > >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 > > > > > > > > > > > > > > > > >>>> 4:39:52 > > > > > > > > > > > > > > > > >>>> PM > > > > > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > >>>> Identity > > > > > > > > > > > > > > > > >>>> and > > > > > > > > > > > > > > > > >>>> Authentication > > > > > > > > > > > > > > > > >>>> Broker > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor Silva > > > > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > >>>>> Hi, > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> Would like to start a discussion > > > > > > > > > > > > > > > > >>>>> about > > > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> enable > > > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > >>>>> Authentication Broker in order > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> supported > > > > > > > > > > > > > > > > >>>>> Chained > > > > > > > > > > > > > > > > >>>>> Federation > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> also Identity Federation. First > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > >>>>> all, > > > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > > > >>>>> background > > > > > > > > > > > > > > > > >>>>> about > > > > > > > > > > > > > > > > >>>>> what > > > > > > > > > > > > > > > > >>>>> this is all about. > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> Currently KeyCloak provides two > > > > > > > > > > > > > > > > >>>>> basic > > > > > > > > > > > > > > > > >>>>> types > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > > > >>>>> (correct > > > > > > > > > > > > > > > > >>>>> me if I'm wrong, please): > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> 1) Local authentication > > > > > > > > > > > > > > > > >>>>> (based > > > > > > > > > > > > > > > > >>>>> on > > > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > > > >>>>> credential > > > > > > > > > > > > > > > > >>>>> type > > > > > > > > > > > > > > > > >>>>> enabled > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> a realm) > > > > > > > > > > > > > > > > >>>>> 2) Social authentication > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> Local authentication is about > > > > > > > > > > > > > > > > >>>>> authenticating > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > > > > > >>>>> locally > > > > > > > > > > > > > > > > >>>>> using > > > > > > > > > > > > > > > > >>>>> KC's own identity store. Nothing > > > > > > > > > > > > > > > > >>>>> special > > > > > > > > > > > > > > > > >>>>> here. > > > > > > > > > > > > > > > > >>>>> And > > > > > > > > > > > > > > > > >>>>> Social > > > > > > > > > > > > > > > > >>>>> Authentication which allows > > > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> choose > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> Social > > > > > > > > > > > > > > > > >>>>> IdP > > > > > > > > > > > > > > > > >>>>> they > > > > > > > > > > > > > > > > >>>>> want > > > > > > > > > > > > > > > > >>>>> to authenticate with. In this > > > > > > > > > > > > > > > > >>>>> case, > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> IdP > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > >>>>> always > > > > > > > > > > > > > > > > >>>>> one > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> built-in social providers > > > > > > > > > > > > > > > > >>>>> supported > > > > > > > > > > > > > > > > >>>>> by > > > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > >>>>> Facebook, > > > > > > > > > > > > > > > > >>>>> Google, > > > > > > > > > > > > > > > > >>>>> Twitter, Github and so forth. > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> When doing social, the user is > > > > > > > > > > > > > > > > >>>>> automatically > > > > > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > > > > > >>>>> in > > > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > > > >>>>> identity store after a > > > > > > > > > > > > > > > > >>>>> successful > > > > > > > > > > > > > > > > >>>>> authentication. > > > > > > > > > > > > > > > > >>>>> The > > > > > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > > > > > >>>>> does > > > > > > > > > > > > > > > > >>>>> not > > > > > > > > > > > > > > > > >>>>> need to fill a registration form > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> can > > > > > > > > > > > > > > > > >>>>> access > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > >>>>> very > > > > > > > > > > > > > > > > >>>>> quickly. During the provisioning > > > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > > > >>>>> basic > > > > > > > > > > > > > > > > >>>>> information > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > >>>>> retrieved > > > > > > > > > > > > > > > > >>>>> from the social provider such as > > > > > > > > > > > > > > > > >>>>> email, > > > > > > > > > > > > > > > > >>>>> firstname > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > > > > > >>>>> forth. > > > > > > > > > > > > > > > > >>>>> These > > > > > > > > > > > > > > > > >>>>> are very basic information, any > > > > > > > > > > > > > > > > >>>>> other > > > > > > > > > > > > > > > > >>>>> information > > > > > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > >>>>> those > > > > > > > > > > > > > > > > >>>>> related with authorization > > > > > > > > > > > > > > > > >>>>> policies > > > > > > > > > > > > > > > > >>>>> - > > > > > > > > > > > > > > > > >>>>> eg.: > > > > > > > > > > > > > > > > >>>>> roles > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> groups > > > > > > > > > > > > > > > > >>>>> - > > > > > > > > > > > > > > > > >>>>> must > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > >>>>> defined later via KC's admin > > > > > > > > > > > > > > > > >>>>> console. > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> Another important characteristic > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> application receives a KC token > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> not > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > >>>>> was > > > > > > > > > > > > > > > > >>>>> issued by > > > > > > > > > > > > > > > > >>>>> the social IdP during the > > > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > > > >>>>> process. > > > > > > > > > > > > > > > > >>>>> If > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > >>>>> wants to consume resources from > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> resource > > > > > > > > > > > > > > > > >>>>> provider > > > > > > > > > > > > > > > > >>>>> he > > > > > > > > > > > > > > > > >>>>> was > > > > > > > > > > > > > > > > >>>>> authenticated it must obtain the > > > > > > > > > > > > > > > > >>>>> access > > > > > > > > > > > > > > > > >>>>> token(again) > > > > > > > > > > > > > > > > >>>>> by > > > > > > > > > > > > > > > > >>>>> itself > > > > > > > > > > > > > > > > >>>>> prior > > > > > > > > > > > > > > > > >>>>> to invoke the resource provider > > > > > > > > > > > > > > > > >>>>> API. > > > > > > > > > > > > > > > > >>>>> Assuming > > > > > > > > > > > > > > > > >>>>> all > > > > > > > > > > > > > > > > >>>>> those > > > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > > > >>>>> providers are based on oAuth 1.0 > > > > > > > > > > > > > > > > >>>>> or > > > > > > > > > > > > > > > > >>>>> 2.0. > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> That said, the Authentication > > > > > > > > > > > > > > > > >>>>> Broker > > > > > > > > > > > > > > > > >>>>> functionality > > > > > > > > > > > > > > > > >>>>> aims > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> cover > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> same use cases but with a lot of > > > > > > > > > > > > > > > > >>>>> more > > > > > > > > > > > > > > > > >>>>> flexibility > > > > > > > > > > > > > > > > >>>>> on > > > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > > > >>>>> you > > > > > > > > > > > > > > > > >>>>> setup > > > > > > > > > > > > > > > > >>>>> identity providers(not only > > > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > > > >>>>> ones) > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > > > > > >>>>> federation > > > > > > > > > > > > > > > > >>>>> protocols they may support such > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > >>>>> SAML, > > > > > > > > > > > > > > > > >>>>> OpenID, > > > > > > > > > > > > > > > > >>>>> oAuth > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > > > > > >>>>> forth. > > > > > > > > > > > > > > > > >>>>> This is useful when an > > > > > > > > > > > > > > > > >>>>> enterprise > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > >>>>> providing > > > > > > > > > > > > > > > > >>>>> services > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > > > > > >>>>> customers(IdP) and does not want > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> manage > > > > > > > > > > > > > > > > >>>>> many > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> many > > > > > > > > > > > > > > > > >>>>> relationships. When using a > > > > > > > > > > > > > > > > >>>>> broker, > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > > > >>>>> steps > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > >>>>> pretty much the same when you > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > >>>>> using > > > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > > > >>>>> authentication, > > > > > > > > > > > > > > > > >>>>> with > > > > > > > > > > > > > > > > >>>>> important differences on how you > > > > > > > > > > > > > > > > >>>>> support > > > > > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > > > > > >>>>> identity > > > > > > > > > > > > > > > > >>>>> providers, different federation > > > > > > > > > > > > > > > > >>>>> protocols, > > > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > > > > > >>>>> and how claims and attributes > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > >>>>> resolved. > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> The brokering functionality can > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > >>>>> done > > > > > > > > > > > > > > > > >>>>> in > > > > > > > > > > > > > > > > >>>>> two > > > > > > > > > > > > > > > > >>>>> ways > > > > > > > > > > > > > > > > >>>>> depending > > > > > > > > > > > > > > > > >>>>> if > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> broker service is acting as a > > > > > > > > > > > > > > > > >>>>> gateway > > > > > > > > > > > > > > > > >>>>> or > > > > > > > > > > > > > > > > >>>>> not. > > > > > > > > > > > > > > > > >>>>> When > > > > > > > > > > > > > > > > >>>>> acting > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > > > > > >>>>> gateway, the broker will respond > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> same > > > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > > > >>>>> issued by the trusted identity > > > > > > > > > > > > > > > > >>>>> provider. > > > > > > > > > > > > > > > > >>>>> For > > > > > > > > > > > > > > > > >>>>> instance, > > > > > > > > > > > > > > > > >>>>> if > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > > > > > >>>>> selects a SAML IdP to > > > > > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > > > > > >>>>> with, > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > >>>>> will > > > > > > > > > > > > > > > > >>>>> receive > > > > > > > > > > > > > > > > >>>>> a SAML Response. In this case, > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > >>>>> must > > > > > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > >>>>> prepared > > > > > > > > > > > > > > > > >>>>> to handle a specific federation > > > > > > > > > > > > > > > > >>>>> protocol. > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> However, the broker service can > > > > > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > >>>>> used > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> completely > > > > > > > > > > > > > > > > >>>>> abstract > > > > > > > > > > > > > > > > >>>>> from the application the > > > > > > > > > > > > > > > > >>>>> protocol > > > > > > > > > > > > > > > > >>>>> used > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > >>>>> user. > > > > > > > > > > > > > > > > >>>>> In > > > > > > > > > > > > > > > > >>>>> this case, the application will > > > > > > > > > > > > > > > > >>>>> just > > > > > > > > > > > > > > > > >>>>> receive > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > >>>>> ordinary > > > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > > > >>>>> after a successful > > > > > > > > > > > > > > > > >>>>> authentication. > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> In both cases, the broker acts > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > >>>>> intermediary > > > > > > > > > > > > > > > > >>>>> where > > > > > > > > > > > > > > > > >>>>> specific > > > > > > > > > > > > > > > > >>>>> security policies can be applied > > > > > > > > > > > > > > > > >>>>> when > > > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > > > >>>>> try > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > > > > > >>>>> themselves against a 3rd party > > > > > > > > > > > > > > > > >>>>> IdP. > > > > > > > > > > > > > > > > >>>>> That > > > > > > > > > > > > > > > > >>>>> brings > > > > > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > > > > > >>>>> lot > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > >>>>> value > > > > > > > > > > > > > > > > >>>>> when > > > > > > > > > > > > > > > > >>>>> you think about auditing, > > > > > > > > > > > > > > > > >>>>> authorization > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > > > > > >>>>> when federation of identities is > > > > > > > > > > > > > > > > >>>>> needed. > > > > > > > > > > > > > > > > >>>>> This > > > > > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > > > > > >>>>> allows > > > > > > > > > > > > > > > > >>>>> existing > > > > > > > > > > > > > > > > >>>>> security infrastructures (eg.: > > > > > > > > > > > > > > > > >>>>> SAML-based > > > > > > > > > > > > > > > > >>>>> infrastructures) > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> benefit > > > > > > > > > > > > > > > > >>>>> from KC's support for cloud, > > > > > > > > > > > > > > > > >>>>> rest > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> mobile > > > > > > > > > > > > > > > > >>>>> use > > > > > > > > > > > > > > > > >>>>> cases. > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>>> I think this is enough to start > > > > > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > > > > > >>>>> discussion. > > > > > > > > > > > > > > > > >>>>> I've > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > >>>>> initial > > > > > > > > > > > > > > > > >>>>> discussion with Stian about all > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> we > > > > > > > > > > > > > > > > >>>>> agreed > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > >>>>> abstract > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > >>>>> protocol from applications > > > > > > > > > > > > > > > > >>>>> should > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > >>>>> prioritized. > > > > > > > > > > > > > > > > >>>>> The > > > > > > > > > > > > > > > > >>>>> main > > > > > > > > > > > > > > > > >>>>> reason is > > > > > > > > > > > > > > > > >>>>> that it makes life easier for > > > > > > > > > > > > > > > > >>>>> applications > > > > > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > > > > > >>>>> they > > > > > > > > > > > > > > > > >>>>> only > > > > > > > > > > > > > > > > >>>>> need > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > >>>>> know > > > > > > > > > > > > > > > > >>>>> about KC tokens and nothing > > > > > > > > > > > > > > > > >>>>> else. > > > > > > > > > > > > > > > > >>>>> However > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > >>>>> brings > > > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > > > >>>>> new > > > > > > > > > > > > > > > > >>>>> requirements around user > > > > > > > > > > > > > > > > >>>>> provisioning > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > >>>>> claim/attribute > > > > > > > > > > > > > > > > >>>>> resolution > > > > > > > > > > > > > > > > >>>>> or mapping. But that would be > > > > > > > > > > > > > > > > >>>>> another > > > > > > > > > > > > > > > > >>>>> thread. > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > >>>> Can you elaborate on "abstract the > > > > > > > > > > > > > > > > >>>> protocol > > > > > > > > > > > > > > > > >>>> from > > > > > > > > > > > > > > > > >>>> applications"? > > > > > > > > > > > > > > > > >>>> Not > > > > > > > > > > > > > > > > >>>> sure what you mean by that. IDP > > > > > > > > > > > > > > > > >>>> federation > > > > > > > > > > > > > > > > >>>> should > > > > > > > > > > > > > > > > >>>> be > > > > > > > > > > > > > > > > >>>> configured > > > > > > > > > > > > > > > > >>>> at > > > > > > > > > > > > > > > > >>>> the > > > > > > > > > > > > > > > > >>>> realm level and really has nothing to do > > > > > > > > > > > > > > > > >>>> with > > > > > > > > > > > > > > > > >>>> applications. > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > >>>> I'm really happy that somebody is doing > > > > > > > > > > > > > > > > >>>> this. > > > > > > > > > > > > > > > > >>>> We're > > > > > > > > > > > > > > > > >>>> getting > > > > > > > > > > > > > > > > >>>> a > > > > > > > > > > > > > > > > >>>> real > > > > > > > > > > > > > > > > >>>> impressive feature set! > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > >>> Sure. What I meant was that the > > > > > > > > > > > > > > > > >>> application > > > > > > > > > > > > > > > > >>> only > > > > > > > > > > > > > > > > >>> knows > > > > > > > > > > > > > > > > >>> about > > > > > > > > > > > > > > > > >>> KC > > > > > > > > > > > > > > > > >>> tokens > > > > > > > > > > > > > > > > >>> nothing else. It will always receive a KC > > > > > > > > > > > > > > > > >>> token > > > > > > > > > > > > > > > > >>> regardless > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > >>> protocol > > > > > > > > > > > > > > > > >>> used > > > > > > > > > > > > > > > > >>> to authenticate the user against a 3rd > > > > > > > > > > > > > > > > >>> party > > > > > > > > > > > > > > > > >>> IdP > > > > > > > > > > > > > > > > >>> (saml, > > > > > > > > > > > > > > > > >>> oidc, > > > > > > > > > > > > > > > > >>> whatever). > > > > > > > > > > > > > > > > >>> The > > > > > > > > > > > > > > > > >>> example I gave was about an user trying > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > >>> authenticate > > > > > > > > > > > > > > > > >>> against > > > > > > > > > > > > > > > > >>> a > > > > > > > > > > > > > > > > >>> SAML > > > > > > > > > > > > > > > > >>> IdP. > > > > > > > > > > > > > > > > >>> In this case, after a successful > > > > > > > > > > > > > > > > >>> authentication > > > > > > > > > > > > > > > > >>> on > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > >>> IdP, > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > >>> IdP > > > > > > > > > > > > > > > > >>> will > > > > > > > > > > > > > > > > >>> issue a token to KC. Then KC will > > > > > > > > > > > > > > > > >>> validate > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > >>> token, > > > > > > > > > > > > > > > > >>> perform > > > > > > > > > > > > > > > > >>> trust > > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > > >>> security checks, do user provisioning and > > > > > > > > > > > > > > > > >>> attribute/claim > > > > > > > > > > > > > > > > >>> resolution > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > >>> finally issue a KC token and redirect the > > > > > > > > > > > > > > > > >>> user > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > >>> application. > > > > > > > > > > > > > > > > >>> If > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > >>> app is configured to use openid in KC > > > > > > > > > > > > > > > > >>> then > > > > > > > > > > > > > > > > >>> it > > > > > > > > > > > > > > > > >>> will > > > > > > > > > > > > > > > > >>> receive > > > > > > > > > > > > > > > > >>> a > > > > > > > > > > > > > > > > >>> openid > > > > > > > > > > > > > > > > >>> token > > > > > > > > > > > > > > > > >>> from KC, not saml ... > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > >>> The other scenario is pretty much the > > > > > > > > > > > > > > > > >>> same. > > > > > > > > > > > > > > > > >>> The > > > > > > > > > > > > > > > > >>> difference > > > > > > > > > > > > > > > > >>> is > > > > > > > > > > > > > > > > >>> that > > > > > > > > > > > > > > > > >>> KC > > > > > > > > > > > > > > > > >>> will > > > > > > > > > > > > > > > > >>> not issue its own token but just replay > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > >>> token > > > > > > > > > > > > > > > > >>> issued > > > > > > > > > > > > > > > > >>> by > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > >>> 3rd > > > > > > > > > > > > > > > > >>> party > > > > > > > > > > > > > > > > >>> IdP to the service provider. > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > >>> I agree that this config goes at the > > > > > > > > > > > > > > > > >>> realm > > > > > > > > > > > > > > > > >>> level. > > > > > > > > > > > > > > > > >>> For > > > > > > > > > > > > > > > > >>> instance, > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > >>> create > > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > > >>> enable providers for being used. However, > > > > > > > > > > > > > > > > >>> I > > > > > > > > > > > > > > > > >>> think > > > > > > > > > > > > > > > > >>> we > > > > > > > > > > > > > > > > >>> would > > > > > > > > > > > > > > > > >>> need > > > > > > > > > > > > > > > > >>> some > > > > > > > > > > > > > > > > >>> specific configuration for applications > > > > > > > > > > > > > > > > >>> as > > > > > > > > > > > > > > > > >>> well. > > > > > > > > > > > > > > > > >>> Specially > > > > > > > > > > > > > > > > >>> when > > > > > > > > > > > > > > > > >>> defining > > > > > > > > > > > > > > > > >>> default roles, mapping attributes. > > > > > > > > > > > > > > > > >>> Another > > > > > > > > > > > > > > > > >>> example > > > > > > > > > > > > > > > > >>> of > > > > > > > > > > > > > > > > >>> application > > > > > > > > > > > > > > > > >>> config > > > > > > > > > > > > > > > > >>> is > > > > > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may want > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > >>> define > > > > > > > > > > > > > > > > >>> scopes > > > > > > > > > > > > > > > > >>> per-application. > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > >>>> -- > > > > > > > > > > > > > > > > >>>> Bill Burke > > > > > > > > > > > > > > > > >>>> JBoss, a division of Red Hat > > > > > > > > > > > > > > > > >>>> http://bill.burkecentral.com > > > > > > > > > > > > > > > > >>>> _______________________________________________ > > > > > > > > > > > > > > > > >>>> keycloak-dev mailing list > > > > > > > > > > > > > > > > >>>> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > >>> _______________________________________________ > > > > > > > > > > > > > > > > >>> keycloak-dev mailing list > > > > > > > > > > > > > > > > >>> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > >> _______________________________________________ > > > > > > > > > > > > > > > > >> keycloak-dev mailing list > > > > > > > > > > > > > > > > >> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Bill Burke > > > > > > > > > > > > > > > > JBoss, a division of Red Hat > > > > > > > > > > > > > > > > http://bill.burkecentral.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, 5 December, 2014 3:41:49 PM Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Friday, December 5, 2014 12:36:53 PM > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > Cc: keycloak-dev(a)lists.jboss.org > > Sent: Friday, 5 December, 2014 3:29:08 PM > > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > Cc: keycloak-dev(a)lists.jboss.org > > > Sent: Friday, December 5, 2014 12:23:53 PM > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > Broker > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > Sent: Friday, 5 December, 2014 3:15:42 PM > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > Broker > > > > > > > > ----- Original Message ----- > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > Sent: Friday, December 5, 2014 12:07:37 PM > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > Broker > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > Sent: Friday, 5 December, 2014 2:57:46 PM > > > > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication > > > > > > Broker > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > Sent: Friday, December 5, 2014 11:43:32 AM > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > Authentication > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > Sent: Friday, 5 December, 2014 2:36:14 PM > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > Authentication > > > > > > > > Broker > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > Sent: Friday, December 5, 2014 10:59:08 AM > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > Authentication > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > Another related thing. We've had a few people ask to be > > > > > > > > > able > > > > > > > > > to > > > > > > > > > login > > > > > > > > > to > > > > > > > > > Keycloak on mobiles using the native social login > > > > > > > > > mechanism. > > > > > > > > > > > > > > > > > > I think the best way to do that is to use the direct grant > > > > > > > > > api > > > > > > > > > and > > > > > > > > > make > > > > > > > > > it > > > > > > > > > possible to call that endpoint passing a IdP id and a token > > > > > > > > > instead > > > > > > > > > of > > > > > > > > > username and password. > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > > > The broker endpoint expects the idp id in order to start the > > > > > > > > authentication > > > > > > > > process. Today, the endpoint also expects KCs authorization > > > > > > > > code > > > > > > > > in > > > > > > > > order > > > > > > > > to > > > > > > > > validate requests from clients and use it as a state to > > > > > > > > validate > > > > > > > > responses > > > > > > > > from the trusted idps. > > > > > > > > > > > > > > > > This authorization code is a blocker for this use case, given > > > > > > > > that > > > > > > > > mobile > > > > > > > > don't have this code and just want to start the > > > > > > > > authentication. > > > > > > > > > > > > > > > > A possible solution would be to change the broker to also > > > > > > > > accept > > > > > > > > a > > > > > > > > client_id > > > > > > > > to reference the mobile app and perform some validations > > > > > > > > based > > > > > > > > on > > > > > > > > that. > > > > > > > > Something like that: > > > > > > > > > > > > > > > > 1) Mobile displays a Facebook button > > > > > > > > 2) User clicks the button and mobile sends a request to KC > > > > > > > > Broker > > > > > > > > with > > > > > > > > the > > > > > > > > idp id and his client_id. > > > > > > > > 3) KC Broker checks if the client_id is valid and creates a > > > > > > > > temporary > > > > > > > > authorization code. > > > > > > > > 4) KC Broker redirect mobile to the chosen IdP to perform > > > > > > > > authentication. > > > > > > > > 5) KC Broker receives a response from the IdP, generate its > > > > > > > > own > > > > > > > > token > > > > > > > > and > > > > > > > > send it back to mobile > > > > > > > > > > > > > > > > Makes sense ? > > > > > > > > > > > > > > No that's not the flow I had in mind. Basically the mobile app > > > > > > > authenticates > > > > > > > with Facebook through the native mechanisms. The app then has > > > > > > > an > > > > > > > access > > > > > > > token, which it would send to Keycloak on the direct grant api > > > > > > > to > > > > > > > obtain > > > > > > > a > > > > > > > Keycloak token. > > > > > > > > > > > > Ahh, now I get what you mean :) > > > > > > > > > > > > Yes, what you said is enough. Then we just need to validate the > > > > > > access > > > > > > token > > > > > > (eg.: using a tokeninfo endpoint). > > > > > > > > > > > > But I think we can also consider that use case I mentioned. You > > > > > > may > > > > > > want > > > > > > to > > > > > > login without forcing the user to redirect to KC login page. > > > > > > > > > > We could just add a query param to the login url that lets you pick > > > > > the > > > > > IdP > > > > > to use by alias? > > > > > > > > > > For example auth/.../login?client_id=...&auth_method=google > > > > > > > > Yes, just like my previously example, we need the client_id. The idp > > > > id/alias > > > > is already there. > > > > > > Sure, was just saying it should be the same URL as the regular login > > > page, > > > but with one extra param to specify the IdP. > > > > > > > > > > > Btw, regarding SAML. SAML does not provide a "validation" endpoint > > > > like > > > > oAuth2/OpenID providers usually provide. AFAIK, there is nothing on > > > > the > > > > specs for that. What can be done here is validate SAML assertions > > > > against > > > > a > > > > WS-Trust STS. Or just trust the assertion based on the signature and > > > > others > > > > standards info along it. > > > > > > > > We can also take a closer look at the oAuth2 SAML bearer token > > > > profile > > > > and > > > > see if it helps. > > > > > > If we could have it for social and OpenID Connect providers for now > > > that'd > > > be > > > good. > > > > Deal. I'll do that. > > > > What about that use case I mentioned ? The one about mobile asking to > > broker > > (not previously issued access_token) an identity provider ? > > Sounds like a nice feature, but I'm not sure if anyone would use it. It > also > has a bit of an issue related to adapters, as they would have to have some > support for it. For example we added a while back the login_hint query > param > from OpenID Connect, which is really only usable from the JS adapter > currently. How does mobile authenticate with KC today ? Users are redirect to KC login page in a web view ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Same for other identity providers, the assumption is the app > > > > > > > has > > > > > > > an > > > > > > > out > > > > > > > of > > > > > > > bounds mechanism to obtain an access token, which is then sent > > > > > > > to > > > > > > > Keycloak > > > > > > > over the direct grant api. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > Sent: Friday, 5 December, 2014 1:45:24 PM > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > Authentication > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > Sent: Friday, December 5, 2014 10:22:10 AM > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > Authentication > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > Looks good. I reckon we can combine the two pages. What > > > > > > > > > > > about > > > > > > > > > > > if > > > > > > > > > > > the > > > > > > > > > > > 'Add > > > > > > > > > > > provider' drop-down is: > > > > > > > > > > > > > > > > > > > > > > OpenID > > > > > > > > > > > SAML > > > > > > > > > > > ------ > > > > > > > > > > > Google > > > > > > > > > > > GitHub > > > > > > > > > > > Facebook > > > > > > > > > > > Twitter > > > > > > > > > > > > > > > > > > > > > > Let's drop social on/off and instead have a > > > > > > > > > > > enable/disable > > > > > > > > > > > button > > > > > > > > > > > on > > > > > > > > > > > each > > > > > > > > > > > provider. > > > > > > > > > > > > > > > > > > > > Sure. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, would be nice if users could set a name or alias > > > > > > > > > > > for > > > > > > > > > > > a > > > > > > > > > > > provider > > > > > > > > > > > instance. This would make the callback url easier to > > > > > > > > > > > use > > > > > > > > > > > (instead > > > > > > > > > > > of > > > > > > > > > > > callback/<UUID> it's callback/<alias>). The user > > > > > > > > > > > federation > > > > > > > > > > > providers > > > > > > > > > > > have > > > > > > > > > > > this. > > > > > > > > > > > > > > > > > > > > One of my first tries was using an alias, just like that. > > > > > > > > > > But > > > > > > > > > > I > > > > > > > > > > preferred > > > > > > > > > > using the UUID and make the configuration more easier. > > > > > > > > > > Beside > > > > > > > > > > that, > > > > > > > > > > the > > > > > > > > > > callback url is just a copy and paste, so I think an > > > > > > > > > > alias > > > > > > > > > > would > > > > > > > > > > not > > > > > > > > > > bring > > > > > > > > > > so much usability, but add one more step when configuring > > > > > > > > > > providers. > > > > > > > > > > > > > > > > > > > > However, if this is an usability requirement for KC I can > > > > > > > > > > change > > > > > > > > > > that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > Sent: Friday, 5 December, 2014 1:08:53 PM > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > Authentication > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > In one of our last discussions, you suggested to > > > > > > > > > > > > leave > > > > > > > > > > > > Social > > > > > > > > > > > > as > > > > > > > > > > > > it > > > > > > > > > > > > is. > > > > > > > > > > > > Although IMO I think we can have a single place to > > > > > > > > > > > > manage > > > > > > > > > > > > both > > > > > > > > > > > > social > > > > > > > > > > > > and > > > > > > > > > > > > user-defined identity providers. Social ones are just > > > > > > > > > > > > OOTB > > > > > > > > > > > > and > > > > > > > > > > > > pre-configured identity providers now. > > > > > > > > > > > > > > > > > > > > > > > > That said, today I'm using separated tabs for social > > > > > > > > > > > > and > > > > > > > > > > > > user-defined. > > > > > > > > > > > > Please, take a look at [1] for more details on how > > > > > > > > > > > > the > > > > > > > > > > > > UI > > > > > > > > > > > > looks > > > > > > > > > > > > like. > > > > > > > > > > > > > > > > > > > > > > > > I've changed social UI a bit in order to provide a > > > > > > > > > > > > specific > > > > > > > > > > > > page > > > > > > > > > > > > for > > > > > > > > > > > > create/update. I've also added a "Show Secret" link > > > > > > > > > > > > to > > > > > > > > > > > > display > > > > > > > > > > > > the > > > > > > > > > > > > client_secret in clear text if user wants to. > > > > > > > > > > > > > > > > > > > > > > > > Beside the enable/disable button, I think another > > > > > > > > > > > > good > > > > > > > > > > > > thing > > > > > > > > > > > > to > > > > > > > > > > > > do > > > > > > > > > > > > is > > > > > > > > > > > > specify > > > > > > > > > > > > a default role(s) for each provider. That can be > > > > > > > > > > > > useful > > > > > > > > > > > > if > > > > > > > > > > > > applications > > > > > > > > > > > > want > > > > > > > > > > > > to perform any kind of authorization based on the > > > > > > > > > > > > identity > > > > > > > > > > > > provider > > > > > > > > > > > > or > > > > > > > > > > > > authentication method used to authenticate an user > > > > > > > > > > > > (eg.: > > > > > > > > > > > > useful > > > > > > > > > > > > for > > > > > > > > > > > > adaptative or multi-level access control). We can > > > > > > > > > > > > also > > > > > > > > > > > > use > > > > > > > > > > > > the > > > > > > > > > > > > "amr" > > > > > > > > > > > > claim > > > > > > > > > > > > in the ID Token, which seems KC is not considering at > > > > > > > > > > > > all. > > > > > > > > > > > > The > > > > > > > > > > > > latter > > > > > > > > > > > > is > > > > > > > > > > > > an > > > > > > > > > > > > important thing to think of, regardless this broker > > > > > > > > > > > > work > > > > > > > > > > > > I'm > > > > > > > > > > > > doing. > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://drive.google.com/file/d/0BwjsrPoH8khWMFBvNUcwYWVHRUU/view?usp=sha... > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > Sent: Friday, December 5, 2014 6:15:15 AM > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > Authentication > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > Having a separate enable/disable for each provider > > > > > > > > > > > > would > > > > > > > > > > > > be > > > > > > > > > > > > good. > > > > > > > > > > > > If > > > > > > > > > > > > you're > > > > > > > > > > > > leaving the social tab as is and adding a separate > > > > > > > > > > > > tab > > > > > > > > > > > > for > > > > > > > > > > > > configuring > > > > > > > > > > > > brokered idp's then we should leave the social > > > > > > > > > > > > enable/disable > > > > > > > > > > > > button, > > > > > > > > > > > > otherwise it depends how it'll look like in the end. > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > Sent: Friday, 5 December, 2014 2:29:37 AM > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > Social has a button to enable/disable it. I'm > > > > > > > > > > > > > wondering > > > > > > > > > > > > > what > > > > > > > > > > > > > to > > > > > > > > > > > > > do > > > > > > > > > > > > > with > > > > > > > > > > > > > the brokered identity providers. Shall we add a > > > > > > > > > > > > > similar > > > > > > > > > > > > > flag > > > > > > > > > > > > > for > > > > > > > > > > > > > that > > > > > > > > > > > > > ? > > > > > > > > > > > > > > > > > > > > > > > > > > I was also wondering if the best would be a flag > > > > > > > > > > > > > in > > > > > > > > > > > > > a > > > > > > > > > > > > > per > > > > > > > > > > > > > provider > > > > > > > > > > > > > basis. > > > > > > > > > > > > > So we can disable/enable a specific provider > > > > > > > > > > > > > (social > > > > > > > > > > > > > or > > > > > > > > > > > > > brokered), > > > > > > > > > > > > > instead of doing that for all. > > > > > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > Pedro Igor > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:42:11 AM > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity and > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:23:24 AM > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > > > and > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 1:13:08 PM > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll go for it then. Will remove the icon url > > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > model > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > leave > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > for users if they want to provide icons for > > > > > > > > > > > > > > > their > > > > > > > > > > > > > > > identity > > > > > > > > > > > > > > > providers. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My point is that icons can be usually served by > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > same > > > > > > > > > > > > > > > server/application > > > > > > > > > > > > > > > or proxy, so download images are not such a big > > > > > > > > > > > > > > > deal. > > > > > > > > > > > > > > > Also, > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > icon > > > > > > > > > > > > > > > url > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > part of the freemarker model and people can do > > > > > > > > > > > > > > > what > > > > > > > > > > > > > > > ever > > > > > > > > > > > > > > > they > > > > > > > > > > > > > > > want > > > > > > > > > > > > > > > with > > > > > > > > > > > > > > > it. > > > > > > > > > > > > > > > What I think will also help in your future > > > > > > > > > > > > > > > plans. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not following. Are you saying that if a named > > > > > > > > > > > > > > image > > > > > > > > > > > > > > 'my-provider.png' > > > > > > > > > > > > > > is > > > > > > > > > > > > > > loaded from a theme, then you can override it in > > > > > > > > > > > > > > another > > > > > > > > > > > > > > theme? > > > > > > > > > > > > > > > > > > > > > > > > > > > > If so, that's basically the same as having a css > > > > > > > > > > > > > > class > > > > > > > > > > > > > > 'my-provider' > > > > > > > > > > > > > > in > > > > > > > > > > > > > > a > > > > > > > > > > > > > > theme. With the exception that with an image you > > > > > > > > > > > > > > end > > > > > > > > > > > > > > up > > > > > > > > > > > > > > with > > > > > > > > > > > > > > having > > > > > > > > > > > > > > to > > > > > > > > > > > > > > require a image per provider per theme per > > > > > > > > > > > > > > language, > > > > > > > > > > > > > > which > > > > > > > > > > > > > > could > > > > > > > > > > > > > > be > > > > > > > > > > > > > > a > > > > > > > > > > > > > > lot > > > > > > > > > > > > > > of > > > > > > > > > > > > > > images for a single provider. Also, buttons for > > > > > > > > > > > > > > accessibility > > > > > > > > > > > > > > should > > > > > > > > > > > > > > be > > > > > > > > > > > > > > defined with text and css, not images that can't > > > > > > > > > > > > > > be > > > > > > > > > > > > > > interpreted. > > > > > > > > > > > > > > You > > > > > > > > > > > > > > also > > > > > > > > > > > > > > still need to modify the theme, so I don't see > > > > > > > > > > > > > > any > > > > > > > > > > > > > > benefits. > > > > > > > > > > > > > > > > > > > > > > > > > > You are right. Having a icon url per provider does > > > > > > > > > > > > > not > > > > > > > > > > > > > makes > > > > > > > > > > > > > sense > > > > > > > > > > > > > if > > > > > > > > > > > > > there > > > > > > > > > > > > > are requirements to change images accordingly to a > > > > > > > > > > > > > theme > > > > > > > > > > > > > or > > > > > > > > > > > > > language. > > > > > > > > > > > > > CSS > > > > > > > > > > > > > makes life easier. > > > > > > > > > > > > > > > > > > > > > > > > > > Will remove that property from the model. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 10:04:33 AM > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated Identity > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:55:21 PM > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > Identity > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Users can now specify a Icon Url to be > > > > > > > > > > > > > > > > rendered > > > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > login > > > > > > > > > > > > > > > > page > > > > > > > > > > > > > > > > when > > > > > > > > > > > > > > > > social > > > > > > > > > > > > > > > > or any other identity provider is configured. > > > > > > > > > > > > > > > > So > > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > just > > > > > > > > > > > > > > > > load > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > image > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > url entered by the user. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Are you saying that users should change the > > > > > > > > > > > > > > > > theme > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > customize > > > > > > > > > > > > > > > > css > > > > > > > > > > > > > > > > if > > > > > > > > > > > > > > > > they > > > > > > > > > > > > > > > > only want to change an icon for a provider ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, there's many issues with having a icon > > > > > > > > > > > > > > > url: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Won't work for internationalization - we > > > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > have > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > now, > > > > > > > > > > > > > > > but > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > will > > > > > > > > > > > > > > > * Image is not a good button - CSS is much > > > > > > > > > > > > > > > better > > > > > > > > > > > > > > > * Doesn't support themes - we allow users to > > > > > > > > > > > > > > > switch > > > > > > > > > > > > > > > l&f > > > > > > > > > > > > > > > by > > > > > > > > > > > > > > > switching > > > > > > > > > > > > > > > themes, > > > > > > > > > > > > > > > but that won't work for a icon url. In the > > > > > > > > > > > > > > > future > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > may > > > > > > > > > > > > > > > also > > > > > > > > > > > > > > > support > > > > > > > > > > > > > > > multiple themes per-realm, for example to > > > > > > > > > > > > > > > depending > > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > devices > > > > > > > > > > > > > > > (one > > > > > > > > > > > > > > > theme for mobiles, one for desktops, etc) > > > > > > > > > > > > > > > * Requires the URL to be hosted somewhere - why > > > > > > > > > > > > > > > require > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > separate > > > > > > > > > > > > > > > call > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > download an image (to a separate server maybe) > > > > > > > > > > > > > > > if > > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > can > > > > > > > > > > > > > > > simply > > > > > > > > > > > > > > > be > > > > > > > > > > > > > > > defined > > > > > > > > > > > > > > > in a single CSS file? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rather than add additional places to define > > > > > > > > > > > > > > > look > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > feel > > > > > > > > > > > > > > > components > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > should in the future make it easier to > > > > > > > > > > > > > > > add/customize > > > > > > > > > > > > > > > themes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > Sent: Tuesday, December 2, 2014 9:42:15 AM > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > Identity > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All look and feel related things including > > > > > > > > > > > > > > > > images > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > stylesheets > > > > > > > > > > > > > > > > should > > > > > > > > > > > > > > > > be > > > > > > > > > > > > > > > > part of themes. This is to allow customizing > > > > > > > > > > > > > > > > them > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > theme. > > > > > > > > > > > > > > > > Also, > > > > > > > > > > > > > > > > an > > > > > > > > > > > > > > > > image is not the correct way to render a > > > > > > > > > > > > > > > > button, > > > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > should > > > > > > > > > > > > > > > > be > > > > > > > > > > > > > > > > defined > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > CSS. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > > > > > > > > > > > > > > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:34:45 PM > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > > Identity > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You shouldn't have icon images for social > > > > > > > > > > > > > > > > > providers. > > > > > > > > > > > > > > > > > They > > > > > > > > > > > > > > > > > should > > > > > > > > > > > > > > > > > be > > > > > > > > > > > > > > > > > specified > > > > > > > > > > > > > > > > > as part of the theme in CSS as is now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > From: "Pedro Igor Silva" > > > > > > > > > > > > > > > > > > <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > Sent: Tuesday, 2 December, 2014 12:22:21 > > > > > > > > > > > > > > > > > > PM > > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > > > Identity > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anyone know where I can get the icons > > > > > > > > > > > > > > > > > > images > > > > > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > social > > > > > > > > > > > > > > > > > > providers > > > > > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > > > > > It > > > > > > > > > > > > > > > > > > seems zocial defines them encoded in > > > > > > > > > > > > > > > > > > some > > > > > > > > > > > > > > > > > > way > > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > CSS. > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > > > need > > > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > provide default images if user does > > > > > > > > > > > > > > > > > > not > > > > > > > > > > > > > > > > > > specify > > > > > > > > > > > > > > > > > > their > > > > > > > > > > > > > > > > > > own. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Or is still possible to use zocial > > > > > > > > > > > > > > > > > > ones > > > > > > > > > > > > > > > > > > ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > From: "Pedro Igor Silva" > > > > > > > > > > > > > > > > > > <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > > > > To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > > > Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > Sent: Thursday, November 27, 2014 9:01:38 > > > > > > > > > > > > > > > > > > PM > > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > > > Identity > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've done some initial work covering > > > > > > > > > > > > > > > > > > both > > > > > > > > > > > > > > > > > > persistence > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > brokering. > > > > > > > > > > > > > > > > > > No > > > > > > > > > > > > > > > > > > UI, yet. I'm focused on the model, > > > > > > > > > > > > > > > > > > rest > > > > > > > > > > > > > > > > > > api > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > brokering > > > > > > > > > > > > > > > > > > functionality > > > > > > > > > > > > > > > > > > for now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What I have is enough to decide if we > > > > > > > > > > > > > > > > > > are > > > > > > > > > > > > > > > > > > aligned > > > > > > > > > > > > > > > > > > about > > > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > functionality. So you can understand > > > > > > > > > > > > > > > > > > how > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > model > > > > > > > > > > > > > > > > > > (and > > > > > > > > > > > > > > > > > > persistence), > > > > > > > > > > > > > > > > > > rest api and brokering functionality > > > > > > > > > > > > > > > > > > looks > > > > > > > > > > > > > > > > > > like. > > > > > > > > > > > > > > > > > > Can > > > > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > > > schedule > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > meeting ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Btw, my branch is here [1]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > https://github.com/pedroigor/keycloak/tree/authentication-broker2 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > Pedro Igor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > > > > > > > > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > > > To: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > Sent: Thursday, November 20, 2014 2:48:49 > > > > > > > > > > > > > > > > > > PM > > > > > > > > > > > > > > > > > > Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > > > Identity > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > Authentication > > > > > > > > > > > > > > > > > > Broker > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Currently adapters can only make authz > > > > > > > > > > > > > > > > > > decisions > > > > > > > > > > > > > > > > > > (@RolesAllowed) > > > > > > > > > > > > > > > > > > based > > > > > > > > > > > > > > > > > > on either realm roles or the roles of one > > > > > > > > > > > > > > > > > > specific > > > > > > > > > > > > > > > > > > application. > > > > > > > > > > > > > > > > > > This > > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > related to 1) too. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/20/2014 11:40 AM, Bolesław > > > > > > > > > > > > > > > > > > Dawidowicz > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > 1) Sounds like something definitely > > > > > > > > > > > > > > > > > > > worth > > > > > > > > > > > > > > > > > > > aiming > > > > > > > > > > > > > > > > > > > for. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/20/2014 09:55 AM, Stian > > > > > > > > > > > > > > > > > > > Thorgersen > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > >> I just wanted to quickly list the > > > > > > > > > > > > > > > > > > >> additional > > > > > > > > > > > > > > > > > > >> work > > > > > > > > > > > > > > > > > > >> we > > > > > > > > > > > > > > > > > > >> discussed > > > > > > > > > > > > > > > > > > >> so > > > > > > > > > > > > > > > > > > >> everyone > > > > > > > > > > > > > > > > > > >> can think about it (in no particular > > > > > > > > > > > > > > > > > > >> order): > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> 1) Mapping of tokens - how do we deal > > > > > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > > > > > >> mapping > > > > > > > > > > > > > > > > > > >> of > > > > > > > > > > > > > > > > > > >> an > > > > > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > > > > > >> token > > > > > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > > > > > >> a KC token? For example an external > > > > > > > > > > > > > > > > > > >> token > > > > > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > > > > > >> attribute > > > > > > > > > > > > > > > > > > >> 'group' > > > > > > > > > > > > > > > > > > >> that > > > > > > > > > > > > > > > > > > >> contains 'sales' and 'manager' could > > > > > > > > > > > > > > > > > > >> be > > > > > > > > > > > > > > > > > > >> mapped > > > > > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > > > > > >> 'manager' > > > > > > > > > > > > > > > > > > >> role > > > > > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > > > > > >> 'sales app in a KC token. Could we use > > > > > > > > > > > > > > > > > > >> Drools? > > > > > > > > > > > > > > > > > > >> This > > > > > > > > > > > > > > > > > > >> could > > > > > > > > > > > > > > > > > > >> also > > > > > > > > > > > > > > > > > > >> be > > > > > > > > > > > > > > > > > > >> used > > > > > > > > > > > > > > > > > > >> in > > > > > > > > > > > > > > > > > > >> user federation to allow more complex > > > > > > > > > > > > > > > > > > >> mapping > > > > > > > > > > > > > > > > > > >> of > > > > > > > > > > > > > > > > > > >> roles/groups > > > > > > > > > > > > > > > > > > >> than > > > > > > > > > > > > > > > > > > >> a > > > > > > > > > > > > > > > > > > >> simple 1-1 > > > > > > > > > > > > > > > > > > >> 2) Retrieving tokens - if an > > > > > > > > > > > > > > > > > > >> application > > > > > > > > > > > > > > > > > > >> wants > > > > > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > > > > > >> retrieve > > > > > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > > > > > >> token (for example to view Facebook > > > > > > > > > > > > > > > > > > >> friends > > > > > > > > > > > > > > > > > > >> if > > > > > > > > > > > > > > > > > > >> user > > > > > > > > > > > > > > > > > > >> logged > > > > > > > > > > > > > > > > > > >> in > > > > > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > > > > > >> Facebook) > > > > > > > > > > > > > > > > > > >> 3) Configure scope - currently for > > > > > > > > > > > > > > > > > > >> social > > > > > > > > > > > > > > > > > > >> we > > > > > > > > > > > > > > > > > > >> only > > > > > > > > > > > > > > > > > > >> request > > > > > > > > > > > > > > > > > > >> a > > > > > > > > > > > > > > > > > > >> very > > > > > > > > > > > > > > > > > > >> limited > > > > > > > > > > > > > > > > > > >> scope (basic profile and email), to > > > > > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > > > > > >> example > > > > > > > > > > > > > > > > > > >> view > > > > > > > > > > > > > > > > > > >> Facebook > > > > > > > > > > > > > > > > > > >> friends > > > > > > > > > > > > > > > > > > >> we'd need to ask for that as well > > > > > > > > > > > > > > > > > > >> 4) Selecting provider - currently in > > > > > > > > > > > > > > > > > > >> social > > > > > > > > > > > > > > > > > > >> (and > > > > > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > > > > > >> first > > > > > > > > > > > > > > > > > > >> pass > > > > > > > > > > > > > > > > > > >> of > > > > > > > > > > > > > > > > > > >> brokering) we have an icon user has to > > > > > > > > > > > > > > > > > > >> select, > > > > > > > > > > > > > > > > > > >> but > > > > > > > > > > > > > > > > > > >> can > > > > > > > > > > > > > > > > > > >> we > > > > > > > > > > > > > > > > > > >> select > > > > > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > > > >> provider in a different way (for > > > > > > > > > > > > > > > > > > >> example > > > > > > > > > > > > > > > > > > >> ask > > > > > > > > > > > > > > > > > > >> user > > > > > > > > > > > > > > > > > > >> for > > > > > > > > > > > > > > > > > > >> email, > > > > > > > > > > > > > > > > > > >> and > > > > > > > > > > > > > > > > > > >> select > > > > > > > > > > > > > > > > > > >> based on email domain) > > > > > > > > > > > > > > > > > > >> 5) Gateway - don't create a KC token, > > > > > > > > > > > > > > > > > > >> but > > > > > > > > > > > > > > > > > > >> just > > > > > > > > > > > > > > > > > > >> forward > > > > > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > > > > > >> token > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> IMO 1) is a killer feature, as it > > > > > > > > > > > > > > > > > > >> would > > > > > > > > > > > > > > > > > > >> allow > > > > > > > > > > > > > > > > > > >> companies > > > > > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > > > > > >> add > > > > > > > > > > > > > > > > > > >> external > > > > > > > > > > > > > > > > > > >> users without having to modify their > > > > > > > > > > > > > > > > > > >> applications. > > > > > > > > > > > > > > > > > > >> Issue > > > > > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > > > > > >> 5) > > > > > > > > > > > > > > > > > > >> is > > > > > > > > > > > > > > > > > > >> that > > > > > > > > > > > > > > > > > > >> applications need to understand more > > > > > > > > > > > > > > > > > > >> than > > > > > > > > > > > > > > > > > > >> one > > > > > > > > > > > > > > > > > > >> token, > > > > > > > > > > > > > > > > > > >> which > > > > > > > > > > > > > > > > > > >> would > > > > > > > > > > > > > > > > > > >> require > > > > > > > > > > > > > > > > > > >> rewriting applications. > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> This work is also somewhat related to > > > > > > > > > > > > > > > > > > >> other > > > > > > > > > > > > > > > > > > >> authentication > > > > > > > > > > > > > > > > > > >> mechanisms > > > > > > > > > > > > > > > > > > >> (for > > > > > > > > > > > > > > > > > > >> example Kerberos ticket, LDAP and > > > > > > > > > > > > > > > > > > >> passwordless). > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> ----- Original Message ----- > > > > > > > > > > > > > > > > > > >>> From: "Pedro Igor Silva" > > > > > > > > > > > > > > > > > > >>> <psilva(a)redhat.com&gt; > > > > > > > > > > > > > > > > > > >>> To: "Bill Burke" <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > > > >>> Cc: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > >>> Sent: Wednesday, 19 November, 2014 > > > > > > > > > > > > > > > > > > >>> 8:27:58 > > > > > > > > > > > > > > > > > > >>> PM > > > > > > > > > > > > > > > > > > >>> Subject: Re: [keycloak-dev] Federated > > > > > > > > > > > > > > > > > > >>> Identity > > > > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > > > > >>> Authentication > > > > > > > > > > > > > > > > > > >>> Broker > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > >>> ----- Original Message ----- > > > > > > > > > > > > > > > > > > >>>> From: "Bill Burke" > > > > > > > > > > > > > > > > > > >>>> <bburke(a)redhat.com&gt; > > > > > > > > > > > > > > > > > > >>>> To: keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > >>>> Sent: Wednesday, November 19, 2014 > > > > > > > > > > > > > > > > > > >>>> 4:39:52 > > > > > > > > > > > > > > > > > > >>>> PM > > > > > > > > > > > > > > > > > > >>>> Subject: Re: [keycloak-dev] > > > > > > > > > > > > > > > > > > >>>> Federated > > > > > > > > > > > > > > > > > > >>>> Identity > > > > > > > > > > > > > > > > > > >>>> and > > > > > > > > > > > > > > > > > > >>>> Authentication > > > > > > > > > > > > > > > > > > >>>> Broker > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > >>>> On 11/19/2014 1:22 PM, Pedro Igor > > > > > > > > > > > > > > > > > > >>>> Silva > > > > > > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > > > >>>>> Hi, > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> Would like to start a > > > > > > > > > > > > > > > > > > >>>>> discussion > > > > > > > > > > > > > > > > > > >>>>> about > > > > > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> enable > > > > > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > > > >>>>> Authentication Broker in > > > > > > > > > > > > > > > > > > >>>>> order > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> supported > > > > > > > > > > > > > > > > > > >>>>> Chained > > > > > > > > > > > > > > > > > > >>>>> Federation > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> also Identity Federation. > > > > > > > > > > > > > > > > > > >>>>> First > > > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > > > >>>>> all, > > > > > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > > > > > >>>>> background > > > > > > > > > > > > > > > > > > >>>>> about > > > > > > > > > > > > > > > > > > >>>>> what > > > > > > > > > > > > > > > > > > >>>>> this is all about. > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> Currently KeyCloak provides > > > > > > > > > > > > > > > > > > >>>>> two > > > > > > > > > > > > > > > > > > >>>>> basic > > > > > > > > > > > > > > > > > > >>>>> types > > > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > > > > > >>>>> (correct > > > > > > > > > > > > > > > > > > >>>>> me if I'm wrong, please): > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> 1) Local authentication > > > > > > > > > > > > > > > > > > >>>>> (based > > > > > > > > > > > > > > > > > > >>>>> on > > > > > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > > > > > >>>>> credential > > > > > > > > > > > > > > > > > > >>>>> type > > > > > > > > > > > > > > > > > > >>>>> enabled > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> a realm) > > > > > > > > > > > > > > > > > > >>>>> 2) Social authentication > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> Local authentication is > > > > > > > > > > > > > > > > > > >>>>> about > > > > > > > > > > > > > > > > > > >>>>> authenticating > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > > > > > > > >>>>> locally > > > > > > > > > > > > > > > > > > >>>>> using > > > > > > > > > > > > > > > > > > >>>>> KC's own identity store. > > > > > > > > > > > > > > > > > > >>>>> Nothing > > > > > > > > > > > > > > > > > > >>>>> special > > > > > > > > > > > > > > > > > > >>>>> here. > > > > > > > > > > > > > > > > > > >>>>> And > > > > > > > > > > > > > > > > > > >>>>> Social > > > > > > > > > > > > > > > > > > >>>>> Authentication which allows > > > > > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> choose > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> Social > > > > > > > > > > > > > > > > > > >>>>> IdP > > > > > > > > > > > > > > > > > > >>>>> they > > > > > > > > > > > > > > > > > > >>>>> want > > > > > > > > > > > > > > > > > > >>>>> to authenticate with. In > > > > > > > > > > > > > > > > > > >>>>> this > > > > > > > > > > > > > > > > > > >>>>> case, > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> IdP > > > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > > > >>>>> always > > > > > > > > > > > > > > > > > > >>>>> one > > > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> built-in social providers > > > > > > > > > > > > > > > > > > >>>>> supported > > > > > > > > > > > > > > > > > > >>>>> by > > > > > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > > > >>>>> Facebook, > > > > > > > > > > > > > > > > > > >>>>> Google, > > > > > > > > > > > > > > > > > > >>>>> Twitter, Github and so > > > > > > > > > > > > > > > > > > >>>>> forth. > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> When doing social, the user > > > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > > > >>>>> automatically > > > > > > > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > > > > > > > >>>>> in > > > > > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > > > > > >>>>> identity store after a > > > > > > > > > > > > > > > > > > >>>>> successful > > > > > > > > > > > > > > > > > > >>>>> authentication. > > > > > > > > > > > > > > > > > > >>>>> The > > > > > > > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > > > > > > > >>>>> does > > > > > > > > > > > > > > > > > > >>>>> not > > > > > > > > > > > > > > > > > > >>>>> need to fill a registration > > > > > > > > > > > > > > > > > > >>>>> form > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> can > > > > > > > > > > > > > > > > > > >>>>> access > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > > > >>>>> very > > > > > > > > > > > > > > > > > > >>>>> quickly. During the > > > > > > > > > > > > > > > > > > >>>>> provisioning > > > > > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > > > > > >>>>> basic > > > > > > > > > > > > > > > > > > >>>>> information > > > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > > > >>>>> retrieved > > > > > > > > > > > > > > > > > > >>>>> from the social provider > > > > > > > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > > > >>>>> email, > > > > > > > > > > > > > > > > > > >>>>> firstname > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > > > > > > > >>>>> forth. > > > > > > > > > > > > > > > > > > >>>>> These > > > > > > > > > > > > > > > > > > >>>>> are very basic information, > > > > > > > > > > > > > > > > > > >>>>> any > > > > > > > > > > > > > > > > > > >>>>> other > > > > > > > > > > > > > > > > > > >>>>> information > > > > > > > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > > > >>>>> those > > > > > > > > > > > > > > > > > > >>>>> related with authorization > > > > > > > > > > > > > > > > > > >>>>> policies > > > > > > > > > > > > > > > > > > >>>>> - > > > > > > > > > > > > > > > > > > >>>>> eg.: > > > > > > > > > > > > > > > > > > >>>>> roles > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> groups > > > > > > > > > > > > > > > > > > >>>>> - > > > > > > > > > > > > > > > > > > >>>>> must > > > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > > > >>>>> defined later via KC's admin > > > > > > > > > > > > > > > > > > >>>>> console. > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> Another important > > > > > > > > > > > > > > > > > > >>>>> characteristic > > > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> application receives a KC > > > > > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> not > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > > > >>>>> was > > > > > > > > > > > > > > > > > > >>>>> issued by > > > > > > > > > > > > > > > > > > >>>>> the social IdP during the > > > > > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > > > > > >>>>> process. > > > > > > > > > > > > > > > > > > >>>>> If > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > > > >>>>> wants to consume resources > > > > > > > > > > > > > > > > > > >>>>> from > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> resource > > > > > > > > > > > > > > > > > > >>>>> provider > > > > > > > > > > > > > > > > > > >>>>> he > > > > > > > > > > > > > > > > > > >>>>> was > > > > > > > > > > > > > > > > > > >>>>> authenticated it must obtain > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> access > > > > > > > > > > > > > > > > > > >>>>> token(again) > > > > > > > > > > > > > > > > > > >>>>> by > > > > > > > > > > > > > > > > > > >>>>> itself > > > > > > > > > > > > > > > > > > >>>>> prior > > > > > > > > > > > > > > > > > > >>>>> to invoke the resource > > > > > > > > > > > > > > > > > > >>>>> provider > > > > > > > > > > > > > > > > > > >>>>> API. > > > > > > > > > > > > > > > > > > >>>>> Assuming > > > > > > > > > > > > > > > > > > >>>>> all > > > > > > > > > > > > > > > > > > >>>>> those > > > > > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > > > > > >>>>> providers are based on oAuth > > > > > > > > > > > > > > > > > > >>>>> 1.0 > > > > > > > > > > > > > > > > > > >>>>> or > > > > > > > > > > > > > > > > > > >>>>> 2.0. > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> That said, the > > > > > > > > > > > > > > > > > > >>>>> Authentication > > > > > > > > > > > > > > > > > > >>>>> Broker > > > > > > > > > > > > > > > > > > >>>>> functionality > > > > > > > > > > > > > > > > > > >>>>> aims > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> cover > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> same use cases but with a > > > > > > > > > > > > > > > > > > >>>>> lot > > > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > > > >>>>> more > > > > > > > > > > > > > > > > > > >>>>> flexibility > > > > > > > > > > > > > > > > > > >>>>> on > > > > > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > > > > > >>>>> you > > > > > > > > > > > > > > > > > > >>>>> setup > > > > > > > > > > > > > > > > > > >>>>> identity providers(not only > > > > > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > > > > > >>>>> ones) > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > > > > > > > >>>>> federation > > > > > > > > > > > > > > > > > > >>>>> protocols they may support > > > > > > > > > > > > > > > > > > >>>>> such > > > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > > > >>>>> SAML, > > > > > > > > > > > > > > > > > > >>>>> OpenID, > > > > > > > > > > > > > > > > > > >>>>> oAuth > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > > > > > > > >>>>> forth. > > > > > > > > > > > > > > > > > > >>>>> This is useful when an > > > > > > > > > > > > > > > > > > >>>>> enterprise > > > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > > > >>>>> providing > > > > > > > > > > > > > > > > > > >>>>> services > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > > > > > > > >>>>> customers(IdP) and does not > > > > > > > > > > > > > > > > > > >>>>> want > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> manage > > > > > > > > > > > > > > > > > > >>>>> many > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> many > > > > > > > > > > > > > > > > > > >>>>> relationships. When using a > > > > > > > > > > > > > > > > > > >>>>> broker, > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> authentication > > > > > > > > > > > > > > > > > > >>>>> steps > > > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > > > >>>>> pretty much the same when > > > > > > > > > > > > > > > > > > >>>>> you > > > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > > > >>>>> using > > > > > > > > > > > > > > > > > > >>>>> social > > > > > > > > > > > > > > > > > > >>>>> authentication, > > > > > > > > > > > > > > > > > > >>>>> with > > > > > > > > > > > > > > > > > > >>>>> important differences on how > > > > > > > > > > > > > > > > > > >>>>> you > > > > > > > > > > > > > > > > > > >>>>> support > > > > > > > > > > > > > > > > > > >>>>> different > > > > > > > > > > > > > > > > > > >>>>> identity > > > > > > > > > > > > > > > > > > >>>>> providers, different > > > > > > > > > > > > > > > > > > >>>>> federation > > > > > > > > > > > > > > > > > > >>>>> protocols, > > > > > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > > > > > > > >>>>> and how claims and > > > > > > > > > > > > > > > > > > >>>>> attributes > > > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > > > >>>>> resolved. > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> The brokering functionality > > > > > > > > > > > > > > > > > > >>>>> can > > > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > > > >>>>> done > > > > > > > > > > > > > > > > > > >>>>> in > > > > > > > > > > > > > > > > > > >>>>> two > > > > > > > > > > > > > > > > > > >>>>> ways > > > > > > > > > > > > > > > > > > >>>>> depending > > > > > > > > > > > > > > > > > > >>>>> if > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> broker service is acting as > > > > > > > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > > > > > > > >>>>> gateway > > > > > > > > > > > > > > > > > > >>>>> or > > > > > > > > > > > > > > > > > > >>>>> not. > > > > > > > > > > > > > > > > > > >>>>> When > > > > > > > > > > > > > > > > > > >>>>> acting > > > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > > > > > > > >>>>> gateway, the broker will > > > > > > > > > > > > > > > > > > >>>>> respond > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> same > > > > > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > > > > > >>>>> issued by the trusted > > > > > > > > > > > > > > > > > > >>>>> identity > > > > > > > > > > > > > > > > > > >>>>> provider. > > > > > > > > > > > > > > > > > > >>>>> For > > > > > > > > > > > > > > > > > > >>>>> instance, > > > > > > > > > > > > > > > > > > >>>>> if > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> user > > > > > > > > > > > > > > > > > > >>>>> selects a SAML IdP to > > > > > > > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > > > > > > > >>>>> with, > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > > > >>>>> will > > > > > > > > > > > > > > > > > > >>>>> receive > > > > > > > > > > > > > > > > > > >>>>> a SAML Response. In this > > > > > > > > > > > > > > > > > > >>>>> case, > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> application > > > > > > > > > > > > > > > > > > >>>>> must > > > > > > > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > > > >>>>> prepared > > > > > > > > > > > > > > > > > > >>>>> to handle a specific > > > > > > > > > > > > > > > > > > >>>>> federation > > > > > > > > > > > > > > > > > > >>>>> protocol. > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> However, the broker service > > > > > > > > > > > > > > > > > > >>>>> can > > > > > > > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > > > >>>>> used > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> completely > > > > > > > > > > > > > > > > > > >>>>> abstract > > > > > > > > > > > > > > > > > > >>>>> from the application the > > > > > > > > > > > > > > > > > > >>>>> protocol > > > > > > > > > > > > > > > > > > >>>>> used > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > > > >>>>> user. > > > > > > > > > > > > > > > > > > >>>>> In > > > > > > > > > > > > > > > > > > >>>>> this case, the application > > > > > > > > > > > > > > > > > > >>>>> will > > > > > > > > > > > > > > > > > > >>>>> just > > > > > > > > > > > > > > > > > > >>>>> receive > > > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > > > >>>>> ordinary > > > > > > > > > > > > > > > > > > >>>>> KC > > > > > > > > > > > > > > > > > > >>>>> token > > > > > > > > > > > > > > > > > > >>>>> after a successful > > > > > > > > > > > > > > > > > > >>>>> authentication. > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> In both cases, the broker > > > > > > > > > > > > > > > > > > >>>>> acts > > > > > > > > > > > > > > > > > > >>>>> as > > > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > > > >>>>> intermediary > > > > > > > > > > > > > > > > > > >>>>> where > > > > > > > > > > > > > > > > > > >>>>> specific > > > > > > > > > > > > > > > > > > >>>>> security policies can be > > > > > > > > > > > > > > > > > > >>>>> applied > > > > > > > > > > > > > > > > > > >>>>> when > > > > > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > > > > > >>>>> try > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> authenticate > > > > > > > > > > > > > > > > > > >>>>> themselves against a 3rd > > > > > > > > > > > > > > > > > > >>>>> party > > > > > > > > > > > > > > > > > > >>>>> IdP. > > > > > > > > > > > > > > > > > > >>>>> That > > > > > > > > > > > > > > > > > > >>>>> brings > > > > > > > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > > > > > > > >>>>> lot > > > > > > > > > > > > > > > > > > >>>>> of > > > > > > > > > > > > > > > > > > >>>>> value > > > > > > > > > > > > > > > > > > >>>>> when > > > > > > > > > > > > > > > > > > >>>>> you think about auditing, > > > > > > > > > > > > > > > > > > >>>>> authorization > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> how > > > > > > > > > > > > > > > > > > >>>>> users > > > > > > > > > > > > > > > > > > >>>>> are > > > > > > > > > > > > > > > > > > >>>>> provisioned > > > > > > > > > > > > > > > > > > >>>>> when federation of > > > > > > > > > > > > > > > > > > >>>>> identities > > > > > > > > > > > > > > > > > > >>>>> is > > > > > > > > > > > > > > > > > > >>>>> needed. > > > > > > > > > > > > > > > > > > >>>>> This > > > > > > > > > > > > > > > > > > >>>>> also > > > > > > > > > > > > > > > > > > >>>>> allows > > > > > > > > > > > > > > > > > > >>>>> existing > > > > > > > > > > > > > > > > > > >>>>> security infrastructures > > > > > > > > > > > > > > > > > > >>>>> (eg.: > > > > > > > > > > > > > > > > > > >>>>> SAML-based > > > > > > > > > > > > > > > > > > >>>>> infrastructures) > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> benefit > > > > > > > > > > > > > > > > > > >>>>> from KC's support for cloud, > > > > > > > > > > > > > > > > > > >>>>> rest > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> mobile > > > > > > > > > > > > > > > > > > >>>>> use > > > > > > > > > > > > > > > > > > >>>>> cases. > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>>> I think this is enough to > > > > > > > > > > > > > > > > > > >>>>> start > > > > > > > > > > > > > > > > > > >>>>> a > > > > > > > > > > > > > > > > > > >>>>> discussion. > > > > > > > > > > > > > > > > > > >>>>> I've > > > > > > > > > > > > > > > > > > >>>>> an > > > > > > > > > > > > > > > > > > >>>>> initial > > > > > > > > > > > > > > > > > > >>>>> discussion with Stian about > > > > > > > > > > > > > > > > > > >>>>> all > > > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> we > > > > > > > > > > > > > > > > > > >>>>> agreed > > > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > > > >>>>> abstract > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > >>>>> protocol from applications > > > > > > > > > > > > > > > > > > >>>>> should > > > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > > > >>>>> prioritized. > > > > > > > > > > > > > > > > > > >>>>> The > > > > > > > > > > > > > > > > > > >>>>> main > > > > > > > > > > > > > > > > > > >>>>> reason is > > > > > > > > > > > > > > > > > > >>>>> that it makes life easier > > > > > > > > > > > > > > > > > > >>>>> for > > > > > > > > > > > > > > > > > > >>>>> applications > > > > > > > > > > > > > > > > > > >>>>> so > > > > > > > > > > > > > > > > > > >>>>> they > > > > > > > > > > > > > > > > > > >>>>> only > > > > > > > > > > > > > > > > > > >>>>> need > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > >>>>> know > > > > > > > > > > > > > > > > > > >>>>> about KC tokens and nothing > > > > > > > > > > > > > > > > > > >>>>> else. > > > > > > > > > > > > > > > > > > >>>>> However > > > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > > > >>>>> brings > > > > > > > > > > > > > > > > > > >>>>> some > > > > > > > > > > > > > > > > > > >>>>> new > > > > > > > > > > > > > > > > > > >>>>> requirements around user > > > > > > > > > > > > > > > > > > >>>>> provisioning > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > >>>>> claim/attribute > > > > > > > > > > > > > > > > > > >>>>> resolution > > > > > > > > > > > > > > > > > > >>>>> or mapping. But that would > > > > > > > > > > > > > > > > > > >>>>> be > > > > > > > > > > > > > > > > > > >>>>> another > > > > > > > > > > > > > > > > > > >>>>> thread. > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > >>>> Can you elaborate on "abstract the > > > > > > > > > > > > > > > > > > >>>> protocol > > > > > > > > > > > > > > > > > > >>>> from > > > > > > > > > > > > > > > > > > >>>> applications"? > > > > > > > > > > > > > > > > > > >>>> Not > > > > > > > > > > > > > > > > > > >>>> sure what you mean by that. IDP > > > > > > > > > > > > > > > > > > >>>> federation > > > > > > > > > > > > > > > > > > >>>> should > > > > > > > > > > > > > > > > > > >>>> be > > > > > > > > > > > > > > > > > > >>>> configured > > > > > > > > > > > > > > > > > > >>>> at > > > > > > > > > > > > > > > > > > >>>> the > > > > > > > > > > > > > > > > > > >>>> realm level and really has nothing > > > > > > > > > > > > > > > > > > >>>> to > > > > > > > > > > > > > > > > > > >>>> do > > > > > > > > > > > > > > > > > > >>>> with > > > > > > > > > > > > > > > > > > >>>> applications. > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > >>>> I'm really happy that somebody is > > > > > > > > > > > > > > > > > > >>>> doing > > > > > > > > > > > > > > > > > > >>>> this. > > > > > > > > > > > > > > > > > > >>>> We're > > > > > > > > > > > > > > > > > > >>>> getting > > > > > > > > > > > > > > > > > > >>>> a > > > > > > > > > > > > > > > > > > >>>> real > > > > > > > > > > > > > > > > > > >>>> impressive feature set! > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > >>> Sure. What I meant was that the > > > > > > > > > > > > > > > > > > >>> application > > > > > > > > > > > > > > > > > > >>> only > > > > > > > > > > > > > > > > > > >>> knows > > > > > > > > > > > > > > > > > > >>> about > > > > > > > > > > > > > > > > > > >>> KC > > > > > > > > > > > > > > > > > > >>> tokens > > > > > > > > > > > > > > > > > > >>> nothing else. It will always receive > > > > > > > > > > > > > > > > > > >>> a > > > > > > > > > > > > > > > > > > >>> KC > > > > > > > > > > > > > > > > > > >>> token > > > > > > > > > > > > > > > > > > >>> regardless > > > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > > > >>> protocol > > > > > > > > > > > > > > > > > > >>> used > > > > > > > > > > > > > > > > > > >>> to authenticate the user against a > > > > > > > > > > > > > > > > > > >>> 3rd > > > > > > > > > > > > > > > > > > >>> party > > > > > > > > > > > > > > > > > > >>> IdP > > > > > > > > > > > > > > > > > > >>> (saml, > > > > > > > > > > > > > > > > > > >>> oidc, > > > > > > > > > > > > > > > > > > >>> whatever). > > > > > > > > > > > > > > > > > > >>> The > > > > > > > > > > > > > > > > > > >>> example I gave was about an user > > > > > > > > > > > > > > > > > > >>> trying > > > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > > > >>> authenticate > > > > > > > > > > > > > > > > > > >>> against > > > > > > > > > > > > > > > > > > >>> a > > > > > > > > > > > > > > > > > > >>> SAML > > > > > > > > > > > > > > > > > > >>> IdP. > > > > > > > > > > > > > > > > > > >>> In this case, after a successful > > > > > > > > > > > > > > > > > > >>> authentication > > > > > > > > > > > > > > > > > > >>> on > > > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > > > >>> IdP, > > > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > > > >>> IdP > > > > > > > > > > > > > > > > > > >>> will > > > > > > > > > > > > > > > > > > >>> issue a token to KC. Then KC will > > > > > > > > > > > > > > > > > > >>> validate > > > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > > > >>> token, > > > > > > > > > > > > > > > > > > >>> perform > > > > > > > > > > > > > > > > > > >>> trust > > > > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > > > > >>> security checks, do user provisioning > > > > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > > > > >>> attribute/claim > > > > > > > > > > > > > > > > > > >>> resolution > > > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > > > >>> finally issue a KC token and redirect > > > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > > > >>> user > > > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > > > >>> application. > > > > > > > > > > > > > > > > > > >>> If > > > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > > > >>> app is configured to use openid in KC > > > > > > > > > > > > > > > > > > >>> then > > > > > > > > > > > > > > > > > > >>> it > > > > > > > > > > > > > > > > > > >>> will > > > > > > > > > > > > > > > > > > >>> receive > > > > > > > > > > > > > > > > > > >>> a > > > > > > > > > > > > > > > > > > >>> openid > > > > > > > > > > > > > > > > > > >>> token > > > > > > > > > > > > > > > > > > >>> from KC, not saml ... > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > >>> The other scenario is pretty much the > > > > > > > > > > > > > > > > > > >>> same. > > > > > > > > > > > > > > > > > > >>> The > > > > > > > > > > > > > > > > > > >>> difference > > > > > > > > > > > > > > > > > > >>> is > > > > > > > > > > > > > > > > > > >>> that > > > > > > > > > > > > > > > > > > >>> KC > > > > > > > > > > > > > > > > > > >>> will > > > > > > > > > > > > > > > > > > >>> not issue its own token but just > > > > > > > > > > > > > > > > > > >>> replay > > > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > > > >>> token > > > > > > > > > > > > > > > > > > >>> issued > > > > > > > > > > > > > > > > > > >>> by > > > > > > > > > > > > > > > > > > >>> the > > > > > > > > > > > > > > > > > > >>> 3rd > > > > > > > > > > > > > > > > > > >>> party > > > > > > > > > > > > > > > > > > >>> IdP to the service provider. > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > >>> I agree that this config goes at the > > > > > > > > > > > > > > > > > > >>> realm > > > > > > > > > > > > > > > > > > >>> level. > > > > > > > > > > > > > > > > > > >>> For > > > > > > > > > > > > > > > > > > >>> instance, > > > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > > > >>> create > > > > > > > > > > > > > > > > > > >>> and > > > > > > > > > > > > > > > > > > >>> enable providers for being used. > > > > > > > > > > > > > > > > > > >>> However, > > > > > > > > > > > > > > > > > > >>> I > > > > > > > > > > > > > > > > > > >>> think > > > > > > > > > > > > > > > > > > >>> we > > > > > > > > > > > > > > > > > > >>> would > > > > > > > > > > > > > > > > > > >>> need > > > > > > > > > > > > > > > > > > >>> some > > > > > > > > > > > > > > > > > > >>> specific configuration for > > > > > > > > > > > > > > > > > > >>> applications > > > > > > > > > > > > > > > > > > >>> as > > > > > > > > > > > > > > > > > > >>> well. > > > > > > > > > > > > > > > > > > >>> Specially > > > > > > > > > > > > > > > > > > >>> when > > > > > > > > > > > > > > > > > > >>> defining > > > > > > > > > > > > > > > > > > >>> default roles, mapping attributes. > > > > > > > > > > > > > > > > > > >>> Another > > > > > > > > > > > > > > > > > > >>> example > > > > > > > > > > > > > > > > > > >>> of > > > > > > > > > > > > > > > > > > >>> application > > > > > > > > > > > > > > > > > > >>> config > > > > > > > > > > > > > > > > > > >>> is > > > > > > > > > > > > > > > > > > >>> when using a OIDC/oAuth IdP. You may > > > > > > > > > > > > > > > > > > >>> want > > > > > > > > > > > > > > > > > > >>> to > > > > > > > > > > > > > > > > > > >>> define > > > > > > > > > > > > > > > > > > >>> scopes > > > > > > > > > > > > > > > > > > >>> per-application. > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > >>>> -- > > > > > > > > > > > > > > > > > > >>>> Bill Burke > > > > > > > > > > > > > > > > > > >>>> JBoss, a division of Red Hat > > > > > > > > > > > > > > > > > > >>>> http://bill.burkecentral.com > > > > > > > > > > > > > > > > > > >>>> _______________________________________________ > > > > > > > > > > > > > > > > > > >>>> keycloak-dev mailing list > > > > > > > > > > > > > > > > > > >>>> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > >>> _______________________________________________ > > > > > > > > > > > > > > > > > > >>> keycloak-dev mailing list > > > > > > > > > > > > > > > > > > >>> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > >> _______________________________________________ > > > > > > > > > > > > > > > > > > >> keycloak-dev mailing list > > > > > > > > > > > > > > > > > > >> keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > Bill Burke > > > > > > > > > > > > > > > > > > JBoss, a division of Red Hat > > > > > > > > > > > > > > > > > > http://bill.burkecentral.com > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > keycloak-dev(a)lists.jboss.org > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >