[keycloak-dev] Federated Identity and Authentication Broker
Stian Thorgersen
stian at redhat.com
Tue Dec 2 07:04:33 EST 2014
----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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 at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at 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 at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at 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 at redhat.com>
> > > To: "Bill Burke" <bburke at redhat.com>
> > > Cc: keycloak-dev at 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 at redhat.com>
> > > To: "Bill Burke" <bburke at redhat.com>
> > > Cc: keycloak-dev at 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 at redhat.com>
> > > To: keycloak-dev at 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 at redhat.com>
> > > >>> To: "Bill Burke" <bburke at redhat.com>
> > > >>> Cc: keycloak-dev at 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 at redhat.com>
> > > >>>> To: keycloak-dev at 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 at lists.jboss.org
> > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>>>
> > > >>> _______________________________________________
> > > >>> keycloak-dev mailing list
> > > >>> keycloak-dev at lists.jboss.org
> > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>>
> > > >> _______________________________________________
> > > >> keycloak-dev mailing list
> > > >> keycloak-dev at 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
More information about the keycloak-dev
mailing list