[keycloak-dev] Federated Identity and Authentication Broker
Stian Thorgersen
stian at redhat.com
Tue Dec 2 06:34:45 EST 2014
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
More information about the keycloak-dev
mailing list