From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, December 5, 2014 11:43:32 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: Friday, 5 December, 2014 2:36:14 PM
> 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: Friday, December 5, 2014 10:59:08 AM
> > Subject: Re: [keycloak-dev] Federated Identity and Authentication Broker
> >
> > Another related thing. We've had a few people ask to be able to login to
> > Keycloak on mobiles using the native social login mechanism.
> >
> > I think the best way to do that is to use the direct grant api and make
> > it
> > possible to call that endpoint passing a IdP id and a token instead of
> > username and password.
> >
> > WDYT?
>
> The broker endpoint expects the idp id in order to start the authentication
> process. Today, the endpoint also expects KCs authorization code in order
> to
> validate requests from clients and use it as a state to validate responses
> from the trusted idps.
>
> This authorization code is a blocker for this use case, given that mobile
> don't have this code and just want to start the authentication.
>
> A possible solution would be to change the broker to also accept a
> client_id
> to reference the mobile app and perform some validations based on that.
> Something like that:
>
> 1) Mobile displays a Facebook button
> 2) User clicks the button and mobile sends a request to KC Broker with the
> idp id and his client_id.
> 3) KC Broker checks if the client_id is valid and creates a temporary
> authorization code.
> 4) KC Broker redirect mobile to the chosen IdP to perform authentication.
> 5) KC Broker receives a response from the IdP, generate its own token and
> send it back to mobile
>
> Makes sense ?
No that's not the flow I had in mind. Basically the mobile app authenticates
with Facebook through the native mechanisms. The app then has an access
token, which it would send to Keycloak on the direct grant api to obtain a
Keycloak token.
Ahh, now I get what you mean :)
Yes, what you said is enough. Then we just need to validate the access token (eg.: using a
tokeninfo endpoint).
But I think we can also consider that use case I mentioned. You may want to login without
forcing the user to redirect to KC login page.
Same for other identity providers, the assumption is the app has an out of
bounds mechanism to obtain an access token, which is then sent to Keycloak
over the direct grant api.
>
> >
> > ----- 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 1:45:24 PM
> > > 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: Friday, December 5, 2014 10:22:10 AM
> > > > Subject: Re: [keycloak-dev] Federated Identity and Authentication
> > > > Broker
> > > >
> > > > Looks good. I reckon we can combine the two pages. What about if the
> > > > 'Add
> > > > provider' drop-down is:
> > > >
> > > > OpenID
> > > > SAML
> > > > ------
> > > > Google
> > > > GitHub
> > > > Facebook
> > > > Twitter
> > > >
> > > > Let's drop social on/off and instead have a enable/disable button
on
> > > > each
> > > > provider.
> > >
> > > Sure.
> > >
> > > >
> > > > Also, would be nice if users could set a name or alias for a
provider
> > > > instance. This would make the callback url easier to use (instead of
> > > > callback/<UUID> it's callback/<alias>). The user
federation providers
> > > > have
> > > > this.
> > >
> > > One of my first tries was using an alias, just like that. But I
> > > preferred
> > > using the UUID and make the configuration more easier. Beside that, the
> > > callback url is just a copy and paste, so I think an alias would not
> > > bring
> > > so much usability, but add one more step when configuring providers.
> > >
> > > However, if this is an usability requirement for KC I can change that.
> > >
> > > >
> > > >
> > > > ----- 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 1:08:53 PM
> > > > > Subject: Re: [keycloak-dev] Federated Identity and
Authentication
> > > > > Broker
> > > > >
> > > > > 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=sha...
> > > > >
> > > > > ----- 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: 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(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
> > > > > >
> > > > >
> > > >
> > >
> >
>