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