Federated Identity and Authentication Broker
by Pedro Igor Silva
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
8 years, 12 months
security proxy prototype
by Bill Burke
I was bored of writing adapters, so I decided to take a break and build
a security proxy. Prototype is functional, but still needs some work.
You can secure any HTTP based app or service with zero changes to the
proxied app. You just specify the host port of the server and then
web.xml-like security constraints. I was able to re-use everything we
had so far. Undertow was insanely modular and already had everything I
needed to piece things together.
Left to do? Testing all constraint parameters, build a config parser
and format, and build a distro. Should take 1 or 2 more days for all of
that.
As a side effect, we now have a pure Undertow adapter.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years
Waiting on new WildFly core
by Stan Silvert
We need the latest version of CLI to use the "upload-provider" and
"upload-server-config" operations with EAP6. So I am waiting on a
WildFly Core release to get a couple of fixes [1][2]. They have been
doing one every 1 to 2 weeks, but I'm guessing they won't do another one
until after the US holiday this week.
Once that is done, EAP6 and AS7 users will need to use the CLI remote
client jar [3] to run the "upload-provider" and "upload-server-config"
operations. The old CLI that comes with EAP will not work for these
two operations. The new CLI works with EAP6 just fine.
If we need to push the Keycloak release out this week or early next
week, please let me know. I'll be on PTO the rest of the week, but I'll
be checking email.
Stan
[1] https://issues.jboss.org/browse/WFCORE-267
[2] https://issues.jboss.org/browse/WFCORE-268
[3] https://developer.jboss.org/wiki/UsingTheCLIRemoteClientJar
9 years
Don't include adapter zips?
by Bill Burke
I was thinking that now that we have so many adapters to just remove
them all from the distro and have separate downloads? Would also allow
us to keep track of how popular a particular adapter is.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years
Revisiting client codes again
by Stian Thorgersen
We currently create a SHA-256 hash to verify the client codes, but would it not be better to use a MAC? Doesn't require any changes to the model as we can use the realm code-secret as the secret for the MAC.
Only change would be to ClientSessionCode.createHashCode:
Mac mac = Mac.getInstance("HmacSHA256");
SecretKeySpec key = new SecretKeySpec(realm.getCodeSecret().getBytes(), "HmacSHA256");
mac.init(key);
mac.update(clientSession.getId().getBytes());
mac.update(HASH_SEPERATOR);
mac.update(clientSession.getNote(ACTION_KEY).getBytes());
return Base64Url.encode(mac.doFinal());
9 years
Rename WildFly subsystem
by Stan Silvert
I've merged the code bases so that we just have a single subsystem for
both WildFly and EAP/AS7. Working great on both (yay!).
So the EAP subsystem will be removed from the code base and I now just
have the WildFly subsystem that works for both.
Can anyone think of a reason why I shouldn't rename this to
"keycloak-subsystem" instead of "keycloak-wildfly-subsystem"? The only
problem I can think of is that it will break existing user's
standalone.xml files that refer to the old name.||
9 years
