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.
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
> > > > >
> > > >
> > >
> >
>