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 3:15:42 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 12:07:37 PM
> 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: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
Yes, just like my previously example, we need the client_id. The idp id/alias
is already there.
Sure, was just saying it should be the same URL as the regular login page, but with one
extra param to specify the IdP.
Btw, regarding SAML. SAML does not provide a "validation" endpoint like
oAuth2/OpenID providers usually provide. AFAIK, there is nothing on the
specs for that. What can be done here is validate SAML assertions against a
WS-Trust STS. Or just trust the assertion based on the signature and others
standards info along it.
We can also take a closer look at the oAuth2 SAML bearer token profile and
see if it helps.
If we could have it for social and OpenID Connect providers for now that'd be good.
>
> >
> > >
> > > 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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>