[keycloak-dev] Federated Identity and Authentication Broker
Bill Burke
bburke at redhat.com
Fri Dec 5 08:28:56 EST 2014
Get rid of the social button?
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
More information about the keycloak-dev
mailing list