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

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.

> > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >