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]
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
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org