[keycloak-dev] Federated Identity and Authentication Broker
Stian Thorgersen
stian at redhat.com
Fri Dec 5 08:33:45 EST 2014
----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 December, 2014 2:28:56 PM
> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
>
> Get rid of the social button?
Yes, that's the idea. One place to configure Identity Providers in general instead of one for "enterprise" and one for social.
Initially I thought keeping social separate would be best, but looking at Pedro's screenshots it seems it would work well to combine the two.
>
> On 12/5/2014 3:15 AM, Stian Thorgersen wrote:
> > 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
> >>
> >
> > _______________________________________________
> > 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
More information about the keycloak-dev
mailing list