Re: [keycloak-dev] Federated Identity and Authentication Broker

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