[keycloak-dev] Federated Identity and Authentication Broker
Pedro Igor Silva
psilva at redhat.com
Fri Dec 5 08:14:55 EST 2014
No problem.
----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Friday, December 5, 2014 10:55:32 AM
Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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 at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at 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.
Please do. If it uses a UUID it also requires updating the provider if you have to re-create the provider for whatever reason. For example I've got keys I use for dev/testing and I've just set the callback to http://localhost:8080/auth/callback/google. As long as I can re-create the provider with the same alias I don't have to touch Google, but if it's a generated UUID I always have to.
>
> >
> >
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at 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=sharing
> > >
> > > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at 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 at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > > > > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > > > > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > > > > > > To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > Cc: keycloak-dev at 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 at redhat.com>
> > > > > > > > > To: keycloak-dev at 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 at redhat.com>
> > > > > > > > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > > > > > > > >>> Cc: keycloak-dev at 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 at redhat.com>
> > > > > > > > > >>>> To: keycloak-dev at 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 at lists.jboss.org
> > > > > > > > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > >>>>
> > > > > > > > > >>> _______________________________________________
> > > > > > > > > >>> keycloak-dev mailing list
> > > > > > > > > >>> keycloak-dev at lists.jboss.org
> > > > > > > > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > > >>>
> > > > > > > > > >> _______________________________________________
> > > > > > > > > >> keycloak-dev mailing list
> > > > > > > > > >> keycloak-dev at 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 at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-dev mailing list
> > > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > keycloak-dev mailing list
> > > > > > > > keycloak-dev at lists.jboss.org
> > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > >
> >
>
More information about the keycloak-dev
mailing list