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>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> 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>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> 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>
>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>> 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>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> 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>
>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>> 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>
>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>> 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>
>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>>> 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>
>>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com>
>>>>> 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>
>>>>>> To: "Bill Burke" <bburke(a)redhat.com>
>>>>>> 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>
>>>>>> To: "Bill Burke" <bburke(a)redhat.com>
>>>>>> 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>
>>>>>> 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>
>>>>>>>>> To: "Bill Burke" <bburke(a)redhat.com>
>>>>>>>>> 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>
>>>>>>>>>> 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