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