The ideal identity system integrates well with the web, and with non-web
applications. The systems that are most seriously used in these realms are
SAML and Kerberos, respectively. But until now, they didn't mix...
As explained in lessons learnt, bring your own identity, forms of identity and even tricks with identities, we have a clear notion of how to conceptually deal with identity.
These structures are presumed to be feasible for the web using one technology, namely SAML, and for most other protocols with another technology, namely Kerberos. The two can even come together with our own work on the KDH CipherSuite for TLS. The one thing that we need to address is how the Kerberos and SAML systems can work together. This introduces quite a bit of research because both systems need enhancements to match well and their coupling needs to be defined and preferrably standardised.
Meet Kerberos
Kerberos is best explained in a dialog that explains how a client, a service and a central realm controller (named the KDC) collaborate to get the client to securely access the service. The client logs on under the KDC for its realm, and in the simplest case the service falls under the same KDC.
When client and service realms differ, a facility for realm crossover is needed. This is defined for Kerberos, but only for statically created realm links. We therefore described dynamic realm crossover based on modern techniques such as DNSSEC and DANE; we have drafted designs that enable such automated linkage. All this is done as part of internet-wide standardisation processes in the Kitten workgroup of the Internet Engineering Task Force. Such standardisation processes represent a major effort, since it involves many experts which judge proposals to achieve the optimal protocol from a multitude of angles.
Recalling the picture for our architecture,
the most innnovative part for Kerberos is the "Identity Perimeter" that conceals internal identities, or permits clients to act on behalf of groups of whom they are members. At present, Kerberos can only offer a generally recognised anonymous identity; but there is no facility for changing to a pseudonym, role or group in current Kerberos systems. We believe this is beneficial to gain control over online presence as well as to permit group co-operative account.
Meet SAML
SAML is a web single sign-on system. When accessing a servive the browser will be redirected to the client's SAML identity provider, which could be an IdP component of the InternetWide.org infrastructure (or, in terms of code projects, an ARPA2 identity-providing component for SAML). The client would logon on this locally-known site or, if that had already been done, skip that step; the client's browser would then be redirected back to the service, carrying an Authentication Statement. On the service provider's end, there would be an authorization decision based on this statement, and the outcome would determine the client's access rights to the service.
Note that, as incorporated into our infrastructure, authorization decisions and access control reside in the server's realm, whereas the identity provider and its release of Authentication Statements runs in the client's realm.
An extra building block in a SAML infrastructure could be a SAML proxy like OpenConext that is a single stepping stone between a collection of identity providers and a collection of service providers. One task we have ahead of ourselves is to integrate with such software, to make it possible to find the identity provider that we build into our APRA2 projects.
Introducing Attribute Statements
One aspect of SAML that is really inspiring is to pass Attribute Statements from identity provider to the authorizing service. Unlike an Authentication Statement that reveals the identity of a client in a verifiable manner, and Attribute Statement is designed to only make verifiable statemenQs that are somewhat general and could apply to many. Example are whether the client is a student, whether he is an adult, or what colour of belt he holds in Jiu Jitsu.
Both types of statements from the identity provider have their purpose; when access is general and there is no need to store individual data, then the attributes suffice. When client-specific storage is required, an identity will be needed to find back the stored details during a future visit. As explained before, we think pseudonyms, roles and groups can can add value in such situations. Even when an identity is provided, it may be helpful to provide attributes; given that the client realm can be trusted to make these attribute statements accurately, they can relieve the service from administering the information, and keeping it up to date.
SAML meets Kerberos
The integration between SAML and Kerberos can enable arbitrary exchanges between the two single sign-on systems. Meaning, login once and from that moment on continue to use that access.
Although many facilities exist to "pre-authenticate" to Kerberos with external mechanisms, and it is certainly possible for a KDC to learn to accept a SAML Authentication Statement or even an Attribute Statement and produce a Kerberos ticket, it is not the logical way to go: This would take credentials from the highly dynamic, externally exposed browser environment and apply them to the more stable desktop / OS environment that hosts Kerberos. The opposite direction appears to be much more reliable.
In short, our aim will be to use Kerberos infrastructure extended with SAML carrying facilities that can then be used in SAML environments. In SAML terminology, we define a SAML Kerberos binding to carry SAML statements over Kerberos' messaging channels.
The SAML information carried around must support authentication. For the client, this will be founded on the origin being the local KDC; for the service, authentication is based on concealment in a ticket that can only have come from the client's KDC as established through realm crossover between the client's KDC and the server's KDC.
As it turns out, Kerberos messages and tickets have various places that can hold SAML statements. Using the technical terms to keep it accurate, the apparent options are:
-
A PrincipalName, covering the client's identifier under a realm, can take on numerous forms; a new and easily readable form could be defined for
attr=valuesettings. -
The AuthorizationData embedded in Tickets can be made to hold a SAML fragment, such as an Attribute Statement or an Authentication Statement. This may be done when crossing over to another realm, but will generally be determined by the local policy on the client's KDC.
-
For realm crossover, we already expressed the intention to have an Identity Perimeter that could optionally replace a client's identity. This issue would arise when a client, contacing his local KDC, needs to crossover to another realm. The KDC can recognise this situation and implement policy to switch to another identity, be it pseudonym, group or role; or he might simply validate a requested identity switch requested by the client during a query for a service ticket.
-
The flows for SAML allow an Authentication Request (sent from the service to the identity provider) to ask for a set of desired attributes, which is not currently possible with the forward-only flow of a Kerberos system. Solutions can probably be constructed by incorporating the set of desired SAML attributes with the DNS record that we need to introduce for realm crossover, to state things about the service such as its Kerberos realm name. This DNS record would also be the place to select whether an identity and/or a set of attributes is required; and even to define whether SAML is welcomed at all during Kerberos exchanges.
This framework would be advantageous to both Kerberos and SAML:
-
Kerberos gains facilities of identity modification, dynamic realm crossover and attribute-based statements that enable simpler filtering in an authorization service;
-
SAML gains accessibility to other protocols than just the web; it gains an additional binding that enhances its security by integrating with the transport level and staying out of control of the same JavaScript level that hosts adverse applications, including arbitrarily sourced advertisements.
In short, there is a lot of work to be done to actually make this integration, but it is such a valuable investment that we believe it deserves our attention.
Go Top