[keycloak-dev] Federated Identity and Authentication Broker
Pedro Igor Silva
psilva at redhat.com
Fri Dec 5 07:08:53 EST 2014
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