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:57:46 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 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.
We could just add a query param to the login url that lets you pick the IdP to use by
alias?
For example auth/.../login?client_id=...&auth_method=google
>
> 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>