A guide to Federated Identity, Icehouse and beyond

TwitterFacebookGoogle+LinkedInRedditStumbleUpon

When I was told to kick off a new developer-focused series of entries for Thoughts on Cloud, I was stunned. First, by the honor that it would be, and then by the realization that I would have to actually write something down. I’m not a writer, not a blogger, the whole thing suddenly seemed kind of daunting.

I figured a bit of my background would help level set the audience (yay for IBM-speak!). I’ve been working on OpenStack for almost two years as a dual core contributor to the Keystone project (OpenStack’s Identity project), and the OpenStackClient project. I’ve dabbled in a few other projects, but my main focus has been Keystone. That said, I’ve worked on some pretty neat things there, like adding OAuth 1.0a support, had a hand in supporting CADF audit events, and most recently supporting Federated Identity.

What is Federated Identity, and why do you keep mentioning it?

Imagine you are working in the IT department of large enterprise company. You already have all of your users in an active directory or LDAP, and you have an identity manager that takes care of all your single sign-on (SSO) problems for web apps. Now you want to start using OpenStack. Prior to the Icehouse release, you would have to create the users in Keystone and assign them roles. This opens up a lot of issues with synchronization, like if an employee leaves or is fired, then you would have to delete the user in two places. Also, there’s additional overhead in setting things up, you would have to create the users in Keystone, then assign the users a bunch of roles too. This isn’t too difficult for a few users, but for a few hundred or thousand, it’s brutal. Headaches all around—especially considering that you already have an identity manager that takes care of all that for you.

The solution is federation, and with the Icehouse release, you can now federate Keystone to your identity manager (by using SAML), and allow “federated users” (remember: these users will not exist in Keystone, they are ephemeral) to access resources.

(Related: Brad Topol summarizes IBM’s contributions to OpenStack’s Icehouse release)

Mapping SAML attributes to Keystone attributes

Though there are several aspects to configuring Federation support for Keystone, I wanted to focus on the mapping portion. A set of mapping rules are essential for federation to work in Keystone. These rules will map the attributes coming from the Identity Manager (let’s call these “remote”), to some Keystone value (let’s call these “local”). I think it’s best to just look at some examples (click image to zoom):

<saml:attributestatement>
	 <saml:attribute name="subject">
	   <saml:attributevalue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">stevemar</saml:attributevalue>
	 </saml:attribute>
	 <saml:attribute name="orgPersonType">
	   <saml:attributevalue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">IBM Regular Employees</saml:attributevalue>
	   <saml:attributevalue xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">SWG</saml:attributevalue>
	</saml:attribute>
  </saml:attributestatement>

What we’re seeing above is a snippet from a SAML Assertion. In this case, the user’s identifying name is “stevemar,” and the user is a part of two groups.

{
	"rules": [
		{
			"local": [
				{
					"user": {
						"name": "{0}"
					}
				}
			],
			"remote": [
				{
					"type": "subject"
				}
			]
		},
		{
			"local": [
				{
					"group": {
						"id": "85a868"
					}
				}
			],
			"remote": [
				{
					"type": "orgPersonType",
					"any_one_of": [
						"IBM Regular Employees",
						"Contractor"
					]
				}
			]
		}
	]
}

Let’s break down what is happening in the mapping rules. In the first rule, Keystone will assign the user’s name to the “subject” value from the SAML assertion—in this case stevemar. In the second rule, Keystone will assign the federated user, the roles given the group “85a868,” since in the SAML assertion, it has an attribute value that matches one of the “any_one_of” values (in this case, “IBM Regular Employees” was matched).

For more information about Federation, consult Keystone’s developer documentation here or the OS-FEDERATION API here.

What to expect in Juno

One of the really neat things we’re working on in the Juno release is to support Keystone2Keystone federation. This new capability will provide the foundation for hybrid cloud support and bursting. Though there are many use cases, they all more or less come down to the same principles. There is a Keystone acting as an Identity Provider (IdP), and another Keystone acting as a Service Provider (SP). Basically, SP would be a public cloud company and IdP would be a private cloud that, at times, may need extra resources and has to borrow the SP’s resources. We plan on supporting this model by basically doing what we did in Icehouse, but in reverse. Since Keystone already knows how to handle a SAML assertion, we need to make Keystone generate an assertion about itself. Once the assertion is generated, we send it off to the SP and let the mapping engine do it’s work. Cool picture with lots of arrows and text is included below:

k2k

I hope you enjoyed reading about Federated Identity and some of the work IBM is doing in OpenStack. I selfishly wanted to conclude on what it means to be an OpenStack developer. Working on OpenStack and on the Keystone team has been a great learning experience. There are very talented and passionate people working on OpenStack, and it’s infectious! Performing countless code reviews, submitting patch after patch, and knowing a person’s IRC handle rather than their name seems normal now. It has been (and continues to be) a great ride.

The following video is a live presentation of the Federated Identity support added in the IceHouse OpenStack release by IBM and CERN and can be leveraged by tools such as IBM Tivoli Federated Identity Manager.

TwitterFacebookGoogle+LinkedInRedditStumbleUpon
Comments Off
Steve Martinelli

About Steve Martinelli

Steve Martinelli is an IBM Staff Software Developer in the SWG Open Technologies Strategy organization. In his current role, Steve leads development on all things Identity for OpenStack, including Authenticating, Authorization, and Auditing. He is focused on contributing to and improving OpenStack, Steve is a Core Contributor to OpenStack's Identity project and Command Line project.
This entry was posted in Developers' Corner, OpenStack and tagged , , , , , , . Bookmark the permalink.