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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)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?

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(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Friday, 5 December, 2014 2:29:37 AM >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >> >> Hi, >> >> Social has a button to enable/disable it. I'm wondering what to do >> with >> the brokered identity providers. Shall we add a similar flag for that >> ? >> >> I was also wondering if the best would be a flag in a per provider >> basis. >> So we can disable/enable a specific provider (social or brokered), >> instead of doing that for all. >> >> Regards. >> Pedro Igor >> >> ----- Original Message ----- >> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Tuesday, December 2, 2014 10:42:11 AM >> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >> >> ----- Original Message ----- >>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Tuesday, December 2, 2014 10:23:24 AM >>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)lists.jboss.org >>>> Sent: Tuesday, 2 December, 2014 1:13:08 PM >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>>> >>>> I'll go for it then. Will remove the icon url from the model and leave >>>> that >>>> for users if they want to provide icons for their identity providers. >>>> >>>> My point is that icons can be usually served by the same >>>> server/application >>>> or proxy, so download images are not such a big deal. Also, the icon url >>>> is >>>> part of the freemarker model and people can do what ever they want with >>>> it. >>>> What I think will also help in your future plans. >>> >>> I'm not following. Are you saying that if a named image 'my-provider.png' >>> is >>> loaded from a theme, then you can override it in another theme? >>> >>> If so, that's basically the same as having a css class 'my-provider' in a >>> theme. With the exception that with an image you end up with having to >>> require a image per provider per theme per language, which could be a lot >>> of >>> images for a single provider. Also, buttons for accessibility should be >>> defined with text and css, not images that can't be interpreted. You also >>> still need to modify the theme, so I don't see any benefits. >> >> You are right. Having a icon url per provider does not makes sense if >> there >> are requirements to change images accordingly to a theme or language. CSS >> makes life easier. >> >> Will remove that property from the model. >> >>> >>>> >>>> ----- Original Message ----- >>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)lists.jboss.org >>>> Sent: Tuesday, December 2, 2014 10:04:33 AM >>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>> Sent: Tuesday, 2 December, 2014 12:55:21 PM >>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>> Broker >>>>> >>>>> Users can now specify a Icon Url to be rendered on the login page when >>>>> social >>>>> or any other identity provider is configured. So we just load the image >>>>> the >>>>> url entered by the user. >>>>> >>>>> Are you saying that users should change the theme or customize css if >>>>> they >>>>> only want to change an icon for a provider ? >>>> >>>> Yes, there's many issues with having a icon url: >>>> >>>> * Won't work for internationalization - we don't have this now, but we >>>> will >>>> * Image is not a good button - CSS is much better >>>> * Doesn't support themes - we allow users to switch l&f by switching >>>> themes, >>>> but that won't work for a icon url. In the future we may also support >>>> multiple themes per-realm, for example to depending on the devices (one >>>> theme for mobiles, one for desktops, etc) >>>> * Requires the URL to be hosted somewhere - why require a separate call >>>> to >>>> download an image (to a separate server maybe) if it can simply be >>>> defined >>>> in a single CSS file? >>>> >>>> Rather than add additional places to define look and feel components we >>>> should in the future make it easier to add/customize themes. >>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>> Sent: Tuesday, December 2, 2014 9:42:15 AM >>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>> Broker >>>>> >>>>> All look and feel related things including images and stylesheets >>>>> should >>>>> be >>>>> part of themes. This is to allow customizing them in the theme. Also, >>>>> an >>>>> image is not the correct way to render a button, it should be defined >>>>> in >>>>> CSS. >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>>> Sent: Tuesday, 2 December, 2014 12:34:45 PM >>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>>> Broker >>>>>> >>>>>> You shouldn't have icon images for social providers. They should be >>>>>> specified >>>>>> as part of the theme in CSS as is now. >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>>>> Sent: Tuesday, 2 December, 2014 12:22:21 PM >>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>>>> Broker >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Anyone know where I can get the icons images for social >>>>>>> providers >>>>>>> ? >>>>>>> It >>>>>>> seems zocial defines them encoded in some way in CSS. I need >>>>>>> that >>>>>>> to >>>>>>> provide default images if user does not specify their own. >>>>>>> >>>>>>> Or is still possible to use zocial ones ? >>>>>>> >>>>>>> Regards. >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>>>> Sent: Thursday, November 27, 2014 9:01:38 PM >>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>>>> Broker >>>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> I've done some initial work covering both persistence and >>>>>>> brokering. >>>>>>> No >>>>>>> UI, yet. I'm focused on the model, rest api and brokering >>>>>>> functionality >>>>>>> for now. >>>>>>> >>>>>>> What I have is enough to decide if we are aligned about this >>>>>>> functionality. So you can understand how the model (and >>>>>>> persistence), >>>>>>> rest api and brokering functionality looks like. Can we schedule >>>>>>> a >>>>>>> meeting ? >>>>>>> >>>>>>> Btw, my branch is here [1]. >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/pedroigor/keycloak/tree/authentication-broker2 >>>>>>> >>>>>>> Regards. >>>>>>> Pedro Igor >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>>> To: keycloak-dev(a)lists.jboss.org >>>>>>> Sent: Thursday, November 20, 2014 2:48:49 PM >>>>>>> Subject: Re: [keycloak-dev] Federated Identity and Authentication >>>>>>> Broker >>>>>>> >>>>>>> Currently adapters can only make authz decisions (@RolesAllowed) >>>>>>> based >>>>>>> on either realm roles or the roles of one specific application. >>>>>>> This >>>>>>> is >>>>>>> related to 1) too. >>>>>>> >>>>>>> On 11/20/2014 11:40 AM, Bolesław Dawidowicz wrote: >>>>>>>> 1) Sounds like something definitely worth aiming for. >>>>>>>> >>>>>>>> On 11/20/2014 09:55 AM, Stian Thorgersen wrote: >>>>>>>>> I just wanted to quickly list the additional work we discussed >>>>>>>>> so >>>>>>>>> everyone >>>>>>>>> can think about it (in no particular order): >>>>>>>>> >>>>>>>>> 1) Mapping of tokens - how do we deal with mapping of an >>>>>>>>> external >>>>>>>>> token >>>>>>>>> to >>>>>>>>> a KC token? For example an external token with attribute 'group' >>>>>>>>> that >>>>>>>>> contains 'sales' and 'manager' could be mapped to 'manager' role >>>>>>>>> for >>>>>>>>> 'sales app in a KC token. Could we use Drools? This could also >>>>>>>>> be >>>>>>>>> used >>>>>>>>> in >>>>>>>>> user federation to allow more complex mapping of roles/groups >>>>>>>>> than >>>>>>>>> a >>>>>>>>> simple 1-1 >>>>>>>>> 2) Retrieving tokens - if an application wants to retrieve the >>>>>>>>> external >>>>>>>>> token (for example to view Facebook friends if user logged in >>>>>>>>> with >>>>>>>>> Facebook) >>>>>>>>> 3) Configure scope - currently for social we only request a very >>>>>>>>> limited >>>>>>>>> scope (basic profile and email), to for example view Facebook >>>>>>>>> friends >>>>>>>>> we'd need to ask for that as well >>>>>>>>> 4) Selecting provider - currently in social (and for first pass >>>>>>>>> of >>>>>>>>> brokering) we have an icon user has to select, but can we select >>>>>>>>> the >>>>>>>>> provider in a different way (for example ask user for email, and >>>>>>>>> select >>>>>>>>> based on email domain) >>>>>>>>> 5) Gateway - don't create a KC token, but just forward the >>>>>>>>> external >>>>>>>>> token >>>>>>>>> >>>>>>>>> IMO 1) is a killer feature, as it would allow companies to add >>>>>>>>> external >>>>>>>>> users without having to modify their applications. Issue with 5) >>>>>>>>> is >>>>>>>>> that >>>>>>>>> applications need to understand more than one token, which would >>>>>>>>> require >>>>>>>>> rewriting applications. >>>>>>>>> >>>>>>>>> This work is also somewhat related to other authentication >>>>>>>>> mechanisms >>>>>>>>> (for >>>>>>>>> example Kerberos ticket, LDAP and passwordless). >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>>>>>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>>>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>>>>>>> Sent: Wednesday, 19 November, 2014 8:27:58 PM >>>>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and >>>>>>>>>> Authentication >>>>>>>>>> Broker >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>>>>>>>>> To: keycloak-dev(a)lists.jboss.org >>>>>>>>>>> Sent: Wednesday, November 19, 2014 4:39:52 PM >>>>>>>>>>> Subject: Re: [keycloak-dev] Federated Identity and >>>>>>>>>>> Authentication >>>>>>>>>>> Broker >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/19/2014 1:22 PM, Pedro Igor Silva wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Would like to start a discussion about how to enable >>>>>>>>>>>> KC >>>>>>>>>>>> as >>>>>>>>>>>> an >>>>>>>>>>>> Authentication Broker in order to supported Chained >>>>>>>>>>>> Federation >>>>>>>>>>>> and >>>>>>>>>>>> also Identity Federation. First of all, some >>>>>>>>>>>> background >>>>>>>>>>>> about >>>>>>>>>>>> what >>>>>>>>>>>> this is all about. >>>>>>>>>>>> >>>>>>>>>>>> Currently KeyCloak provides two basic types of >>>>>>>>>>>> authentication >>>>>>>>>>>> (correct >>>>>>>>>>>> me if I'm wrong, please): >>>>>>>>>>>> >>>>>>>>>>>> 1) Local authentication (based on some credential >>>>>>>>>>>> type >>>>>>>>>>>> enabled >>>>>>>>>>>> to >>>>>>>>>>>> a realm) >>>>>>>>>>>> 2) Social authentication >>>>>>>>>>>> >>>>>>>>>>>> Local authentication is about authenticating the user >>>>>>>>>>>> locally >>>>>>>>>>>> using >>>>>>>>>>>> KC's own identity store. Nothing special here. And >>>>>>>>>>>> Social >>>>>>>>>>>> Authentication which allows users to choose the Social >>>>>>>>>>>> IdP >>>>>>>>>>>> they >>>>>>>>>>>> want >>>>>>>>>>>> to authenticate with. In this case, the IdP is always >>>>>>>>>>>> one >>>>>>>>>>>> of >>>>>>>>>>>> the >>>>>>>>>>>> built-in social providers supported by KC such as >>>>>>>>>>>> Facebook, >>>>>>>>>>>> Google, >>>>>>>>>>>> Twitter, Github and so forth. >>>>>>>>>>>> >>>>>>>>>>>> When doing social, the user is automatically >>>>>>>>>>>> provisioned >>>>>>>>>>>> in >>>>>>>>>>>> KC >>>>>>>>>>>> identity store after a successful authentication. The >>>>>>>>>>>> user >>>>>>>>>>>> does >>>>>>>>>>>> not >>>>>>>>>>>> need to fill a registration form and can access the >>>>>>>>>>>> application >>>>>>>>>>>> very >>>>>>>>>>>> quickly. During the provisioning some basic >>>>>>>>>>>> information >>>>>>>>>>>> is >>>>>>>>>>>> retrieved >>>>>>>>>>>> from the social provider such as email, firstname and >>>>>>>>>>>> so >>>>>>>>>>>> forth. >>>>>>>>>>>> These >>>>>>>>>>>> are very basic information, any other information such >>>>>>>>>>>> as >>>>>>>>>>>> those >>>>>>>>>>>> related with authorization policies - eg.: roles and >>>>>>>>>>>> groups >>>>>>>>>>>> - >>>>>>>>>>>> must >>>>>>>>>>>> be >>>>>>>>>>>> defined later via KC's admin console. >>>>>>>>>>>> >>>>>>>>>>>> Another important characteristic of social >>>>>>>>>>>> authentication >>>>>>>>>>>> is >>>>>>>>>>>> that >>>>>>>>>>>> the >>>>>>>>>>>> application receives a KC token and not the token that >>>>>>>>>>>> was >>>>>>>>>>>> issued by >>>>>>>>>>>> the social IdP during the authentication process. If >>>>>>>>>>>> the >>>>>>>>>>>> application >>>>>>>>>>>> wants to consume resources from the resource provider >>>>>>>>>>>> he >>>>>>>>>>>> was >>>>>>>>>>>> authenticated it must obtain the access token(again) >>>>>>>>>>>> by >>>>>>>>>>>> itself >>>>>>>>>>>> prior >>>>>>>>>>>> to invoke the resource provider API. Assuming all >>>>>>>>>>>> those >>>>>>>>>>>> social >>>>>>>>>>>> providers are based on oAuth 1.0 or 2.0. >>>>>>>>>>>> >>>>>>>>>>>> That said, the Authentication Broker functionality >>>>>>>>>>>> aims >>>>>>>>>>>> to >>>>>>>>>>>> cover >>>>>>>>>>>> the >>>>>>>>>>>> same use cases but with a lot of more flexibility on >>>>>>>>>>>> how >>>>>>>>>>>> you >>>>>>>>>>>> setup >>>>>>>>>>>> identity providers(not only social ones) and the >>>>>>>>>>>> different >>>>>>>>>>>> federation >>>>>>>>>>>> protocols they may support such as SAML, OpenID, oAuth >>>>>>>>>>>> and >>>>>>>>>>>> so >>>>>>>>>>>> forth. >>>>>>>>>>>> This is useful when an enterprise is providing >>>>>>>>>>>> services >>>>>>>>>>>> to >>>>>>>>>>>> different >>>>>>>>>>>> customers(IdP) and does not want to manage many to >>>>>>>>>>>> many >>>>>>>>>>>> relationships. When using a broker, the authentication >>>>>>>>>>>> steps >>>>>>>>>>>> are >>>>>>>>>>>> pretty much the same when you are using social >>>>>>>>>>>> authentication, >>>>>>>>>>>> with >>>>>>>>>>>> important differences on how you support different >>>>>>>>>>>> identity >>>>>>>>>>>> providers, different federation protocols, how users >>>>>>>>>>>> are >>>>>>>>>>>> provisioned >>>>>>>>>>>> and how claims and attributes are resolved. >>>>>>>>>>>> >>>>>>>>>>>> The brokering functionality can be done in two ways >>>>>>>>>>>> depending >>>>>>>>>>>> if >>>>>>>>>>>> the >>>>>>>>>>>> broker service is acting as a gateway or not. When >>>>>>>>>>>> acting >>>>>>>>>>>> as >>>>>>>>>>>> a >>>>>>>>>>>> gateway, the broker will respond to the application >>>>>>>>>>>> the >>>>>>>>>>>> same >>>>>>>>>>>> token >>>>>>>>>>>> issued by the trusted identity provider. For instance, >>>>>>>>>>>> if >>>>>>>>>>>> the >>>>>>>>>>>> user >>>>>>>>>>>> selects a SAML IdP to authenticate with, the >>>>>>>>>>>> application >>>>>>>>>>>> will >>>>>>>>>>>> receive >>>>>>>>>>>> a SAML Response. In this case, the application must >>>>>>>>>>>> also >>>>>>>>>>>> be >>>>>>>>>>>> prepared >>>>>>>>>>>> to handle a specific federation protocol. >>>>>>>>>>>> >>>>>>>>>>>> However, the broker service can also be used to >>>>>>>>>>>> completely >>>>>>>>>>>> abstract >>>>>>>>>>>> from the application the protocol used to authenticate >>>>>>>>>>>> an >>>>>>>>>>>> user. >>>>>>>>>>>> In >>>>>>>>>>>> this case, the application will just receive an >>>>>>>>>>>> ordinary >>>>>>>>>>>> KC >>>>>>>>>>>> token >>>>>>>>>>>> after a successful authentication. >>>>>>>>>>>> >>>>>>>>>>>> In both cases, the broker acts as an intermediary >>>>>>>>>>>> where >>>>>>>>>>>> specific >>>>>>>>>>>> security policies can be applied when users try to >>>>>>>>>>>> authenticate >>>>>>>>>>>> themselves against a 3rd party IdP. That brings a lot >>>>>>>>>>>> of >>>>>>>>>>>> value >>>>>>>>>>>> when >>>>>>>>>>>> you think about auditing, authorization and how users >>>>>>>>>>>> are >>>>>>>>>>>> provisioned >>>>>>>>>>>> when federation of identities is needed. This also >>>>>>>>>>>> allows >>>>>>>>>>>> existing >>>>>>>>>>>> security infrastructures (eg.: SAML-based >>>>>>>>>>>> infrastructures) >>>>>>>>>>>> to >>>>>>>>>>>> benefit >>>>>>>>>>>> from KC's support for cloud, rest and mobile use >>>>>>>>>>>> cases. >>>>>>>>>>>> >>>>>>>>>>>> I think this is enough to start a discussion. I've an >>>>>>>>>>>> initial >>>>>>>>>>>> discussion with Stian about all that and we agreed >>>>>>>>>>>> that >>>>>>>>>>>> abstract >>>>>>>>>>>> the >>>>>>>>>>>> protocol from applications should be prioritized. The >>>>>>>>>>>> main >>>>>>>>>>>> reason is >>>>>>>>>>>> that it makes life easier for applications so they >>>>>>>>>>>> only >>>>>>>>>>>> need >>>>>>>>>>>> to >>>>>>>>>>>> know >>>>>>>>>>>> about KC tokens and nothing else. However that brings >>>>>>>>>>>> some >>>>>>>>>>>> new >>>>>>>>>>>> requirements around user provisioning and >>>>>>>>>>>> claim/attribute >>>>>>>>>>>> resolution >>>>>>>>>>>> or mapping. But that would be another thread. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Can you elaborate on "abstract the protocol from >>>>>>>>>>> applications"? >>>>>>>>>>> Not >>>>>>>>>>> sure what you mean by that. IDP federation should be >>>>>>>>>>> configured >>>>>>>>>>> at >>>>>>>>>>> the >>>>>>>>>>> realm level and really has nothing to do with applications. >>>>>>>>>>> >>>>>>>>>>> I'm really happy that somebody is doing this. We're getting a >>>>>>>>>>> real >>>>>>>>>>> impressive feature set! >>>>>>>>>> >>>>>>>>>> Sure. What I meant was that the application only knows about KC >>>>>>>>>> tokens >>>>>>>>>> nothing else. It will always receive a KC token regardless the >>>>>>>>>> protocol >>>>>>>>>> used >>>>>>>>>> to authenticate the user against a 3rd party IdP (saml, oidc, >>>>>>>>>> whatever). >>>>>>>>>> The >>>>>>>>>> example I gave was about an user trying to authenticate against >>>>>>>>>> a >>>>>>>>>> SAML >>>>>>>>>> IdP. >>>>>>>>>> In this case, after a successful authentication on the IdP, the >>>>>>>>>> IdP >>>>>>>>>> will >>>>>>>>>> issue a token to KC. Then KC will validate the token, perform >>>>>>>>>> trust >>>>>>>>>> and >>>>>>>>>> security checks, do user provisioning and attribute/claim >>>>>>>>>> resolution >>>>>>>>>> to >>>>>>>>>> finally issue a KC token and redirect the user to the >>>>>>>>>> application. >>>>>>>>>> If >>>>>>>>>> the >>>>>>>>>> app is configured to use openid in KC then it will receive a >>>>>>>>>> openid >>>>>>>>>> token >>>>>>>>>> from KC, not saml ... >>>>>>>>>> >>>>>>>>>> The other scenario is pretty much the same. The difference is >>>>>>>>>> that >>>>>>>>>> KC >>>>>>>>>> will >>>>>>>>>> not issue its own token but just replay the token issued by the >>>>>>>>>> 3rd >>>>>>>>>> party >>>>>>>>>> IdP to the service provider. >>>>>>>>>> >>>>>>>>>> I agree that this config goes at the realm level. For instance, >>>>>>>>>> to >>>>>>>>>> create >>>>>>>>>> and >>>>>>>>>> enable providers for being used. However, I think we would need >>>>>>>>>> some >>>>>>>>>> specific configuration for applications as well. Specially when >>>>>>>>>> defining >>>>>>>>>> default roles, mapping attributes. Another example of >>>>>>>>>> application >>>>>>>>>> config >>>>>>>>>> is >>>>>>>>>> when using a OIDC/oAuth IdP. You may want to define scopes >>>>>>>>>> per-application. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Bill Burke >>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> keycloak-dev mailing list >>>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> keycloak-dev mailing list >>>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> keycloak-dev mailing list >>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Bill Burke >>>>>>> JBoss, a division of Red Hat >>>>>>> http://bill.burkecentral.com >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev