7:22 p.m.
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.
I've already started something related to this. My initial work is about
supporting custom SAML and OpenID IdPs. Right now I'm using a PicketLink SAML IdP,
Google OIDC and SalesForce OIDC. I'm still gathering what we need in terms of
configuration. But the idea is a single protocol implementation to be able to manage
different IdP instances. For instance, the "social providers" would be just OOTB
implementations for all those common social networks. From an initial discussion with
Stian we agreed that we should keep the "Social Authentication" concept for the
sake of users. However, internally we would need to refactor the Social SPI in order to
decouple oAuth2 from it and support other protocols such as SAML.
That said, the first thing would be change the Social SPI without introduce any new
functionality. But prepare it to support the next feature set.
Any thoughts ?
Regards.
Pedro Igor