You’d think with a name like Bandit, this project might be up to something shady. Far from what its name implies, the Bandit project is less about stealing things and more about securing them. You’ll find there are components and solutions that help you deal with identities in easier and more secure ways than ever before. One case in point is a new set of reference applications which bring Microsoft CardSpace support to your Linux world. Of course, this isn’t all that the Bandit project does. It works closely with the Higgins project and other industry leaders to provide an array of identity-centric tools and applications.
> Bandit? Higgins? What Are You Talking About?
It was around a year ago that a handful of us at Novell put up a Web site at bandit-project.org. The open source Bandit project set a course to “invent new Identity DNA” (after figuring out what that meant). We decided the project should deliver components and solutions that provide consistent identity services for authentication, authorization and auditing. Work began on a common identity framework, role engine and audit framework. The existing CASA component was also brought on board. (See bandit-project.org/index.php/Common_Authentication_Services_Adapter_(CASA).)
While creating a common identity framework (APIs and code for dealing with identities from all kinds of different sources), we discovered the Higgins project (eclipse.org/higgins). The Higgins project had several goals that overlapped Bandit’s—especially along the lines of common identity. Check out the charter on the Higgins home page and the overview on the Bandit home page.
Rather than competing with the Higgins project, we joined them and pooled our overlapping efforts. Now the Higgins project is focused on common identity framework architecture and components, and the Bandit project will continue to provide higher-level components and solutions around authentication, authorization and auditing.
> That’s really nice. So how does it help me?
As time goes by, you should see a growing set of identity-related solutions come out of the Bandit project. While there’s a long term vision for changing the identity landscape, there are also a lot of immediate problems we all face day to day. Let’s talk about a few of those problems and how they’re being fixed right now.
Who am I really? When I log into flickr, I’m jim_sermersheim. At last.fm, I’m psilly, at work, I’m jimse, and I’m jsermersheim somewhere else—I forget where. Having and working with all these identities can be annoying. Sometimes I wish I could use one name for all these services. Other times, I want just the opposite. When I’m shopping on Amazon.com for a movie, I’d like to use an account which will cause it to be shipped to my house. When I’m buying a book for work, I want that sent to my office.
So, I have this problem where I may want to use a shared or different persona for each site I visit. If I could be the same person at flickr and last.fm, that would be great. On the other hand, I might want to be Trogdor The Burninator when I’m playing an online game, and nowhere else. Sometimes I want to be “Jim at work”, and other times “Jim at home”. Moreover, when I move, I want to change my mailing address once, not dozens of times.
Tell us a little about yourself
Ugh, another Web form! I’m pretty lazy, but even my most motivated friends get tired of creating new accounts and typing the same things over and over again when they visit new Web sites. Yes, there are browser tools that help with this, but the information they store is limited and local to a particular machine.
Even if the issues above were solved, we still have a problem of trust. Sure, when I list my hobbies at livejournal.com, no one is too worried about me lying. However, if I’m trying to buy a bottle of wine, I can’t just say I’m over 21. I need to prove it. We need a way to present certain identity information that is issued by some trusted party (like a Division of Motor Vehicles).
Another problem with the ways our identities are stored and used is in where the information exists, and who has access to it. Let’s assume there’s a nice way to organize my identities and their respective attributes. Let’s also assume there’s a way of presenting trusted information about myself when needed. I still need a way to be in control of what gets released to whom. A conference registration form might require my name and address. At the same time, it would like—but not require—my phone number, salary range and hobbies. To avoid being the target of direct marketing, I’d like to release only the required information. Also, I’d rather keep my identity information in a few places that I trust than have it spread all over the Internet like it is today.
The identity landscape is changing. You’ve probably heard phrases like Identity 2.0 and User-centric identity. People want these problems solved, and convergence on solutions is becoming a reality. One solution to the problems above has its roots in the notion of an Identity Metasystem. This concept was originally developed by Microsoft. They have a Windows-only implementation of this concept which is called CardSpace.
Before you stop reading, no, I’m not trying to sell you a Microsoft solution. What I want to do is show you how the Identity Metasystem works, and how implementations have been built to interoperate with one another. Even better, I want to show how you can participate in this movement using cross-platform tools. If after reading this, you’re hungry for more on the Identity Metasystem, either Google the term, or start at identityblog.com/stories/2005/07/05/IdentityMetasystem.htm.
Think of InfoCards like the cards you carry around with you. I’m talking about your driver’s license, membership and affiliation cards, and credit cards.
> What Makes Up The Identity Metasystem?
It’s really pretty simple actually. (see Figure 1.) There are basically three players in this system. First, there is what we call an Identity Agent. This is what represents you. An Identity Agent is typically a Web browser, Client application, or whatever else is representing a user trying to access some service. Identity Agents allow users to manage and select identities when they need to present them to a service.
Next, there is the service the user is accessing or using. We call this a Service Provider. Sometimes you’ll hear it referred to as a Relying Party. Examples of Service Providers include Web services and enterprise applications (think of online stores, travel booking tools, etc.). Really, it’s any application that needs information about the user who is accessing it. The kind of information it needs depends on the application. It could be an employee ID, shipping address, phone number or whatever.
Finally, there are Identity Providers. These store a user’s identity information and are capable of constructing, signing and encrypting identity information for presentation to the Service Provider. (See Anatomy of an Identity Provider.)
Something must exist which moves from player to player in this system. In fact, there are two things. From the user’s point of view, it’s all about Information Cards (or InfoCards for short), while the Service Provider and Identity Provider are interested in Security Tokens.
In the digital identity world, Claims are things you say about yourself or things someone else says about you. I can make the claim that my eye color is blue. The FBI can make a claim that I'm not on a watch-list (or that I am).
If you have experience with eDirectory or any other LDAP server, you'll see that claims are like attributes. A claim has two parts: the claim type and the claim value. Claim types are URIs and describe what the claim is about. (A URI is a superset of URL and stands for Universal Resource Identifier; it doesn't necessarily point at the location of a thing, but only names it.) An example is http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname. A Claim value is just that—the value of the claim. If a claim were made about me, and its type was .../surname like the one above, the value would be the string “Sermersheim”. (Too bad there's not also a pronunciation guide; that would save me a lot of time.) In Microsoft's implementation (CardSpace), more than a dozen claims can be set on a Personal Card. This limitation does not extend to Managed Cards, nor does it need to extend to non-Microsoft Personal Cards. You can see the claim types for CardSpace Personal Cards at bandit-project.org/index.php/CardSpaceClaims.
Think of InfoCards like the cards you carry around with you. I’m talking about your driver’s license, membership and affiliation cards, and credit cards. When you need to prove your identity and present your age at a liquor store, you can use your driver’s license. To buy shoes, you might use a credit card. It’s the same with InfoCards. We’ll talk more about these in a bit. The point is that InfoCards share these similarities with the types of cards you carry around:
- You posses a handful of cards.
- You present cards to give some information about yourself.
- You chose cards that are appropriate for the situation.
Thinking again about the cards you carry around, consider how some of them contain useful information (like a driver’s license), and others are more like pointers to where further information can be gathered (like an ATM card). In either case, some information about you needs to be gathered and presented to whomever or whatever needs it. A Security Token is a standard way of packaging and presenting this data.
Security Tokens contain identity information (called Claims) such as phoneNumber=“800-555-1212”, as well as security and policy-related information. See Identity Claims for more information on claims. A Security Token will state where it came from. This is called the issuing Security Token Service (STS). This is important in situations where the receiver of that token needs to know who is making the claims (as in the example of a liquor store trusting only a DMV to make claims about my age).
> What’s in a Card? How do I get one?
There are things I say about myself, and there are things others say about me (and let’s hope you never hear them). What I say about myself tends to be less trusted than what I can get others to say about me—especially when those others are my bank and the government. So it follows that InfoCards can come from me, or from some trusted entity. InfoCards that I create are called Personal Cards, and those that come from a trusted entity are called Managed Cards. In either case, InfoCards are made up of a name, card ID, and an image to help people identify them. Aside from that, what they contain differs a little.
To build a Personal Card, I fire up an application commonly called a Card Manager or Card Selector User Interface. This is a part of the Identity Agent. It’s software running on my computer and allows me to manage (create, delete, export and import) my InfoCards. It’s often the same application that lets me pick a card to use when I’m ready to access some service. When I use the Card Manager to create a card, it prompts me to name the card and enter information (called Claims) about myself. A Personal Card essentially carries these “self-asserted claims” with it. (See Creating Your Own Personal Card for instructions on building your own.)
A Managed Card—one that can be used to get some trusted entity to make claims about me—is a bit different from a Personal Card. First, I get these from the Identity Provider—the trusted entity—which will be used to make claims about me. Also, unlike a Personal Card, a Managed Card doesn’t hold Claim Values. Instead it holds a pointer to (the address of) the Identity Provider which will make claims about me. It also holds the Claim Types that can be produced for me by that Identity Provider, along with some authentication and other details.
The Identity Provider will have some way for me to get a Managed Card. What that way is depends on the type of Identity Provider, how it is deployed and what it’s used for. Often there’s a Web site associated with the Identity Provider from which I can get a card. When I get a card from an Identity Provider, I might have to log in or create an account. In the end, the Identity Provider will give me a card which I can then import into my Card Manager.
> How does this all work together?
Let’s walk through an example of Mary reserving a car rental at a Web site. Now just because I seem hung up on using Web services as I talk about InfoCards doesn’t mean that’s the only scenario they apply to. The same model can be used with any application which needs information about identities (including logging in). We’ll use the numbered arrows in Figure 1.) to walk through this example.
Mary is using an operating system and Web browser which is InfoCard-enabled. This basically means her Web browser knows about Web pages which accept InfoCard tokens, and there’s a Card Selector UI available. With her Card Selector UI, Mary has already created some Personal Cards and imported some Managed Cards from different Identity Providers.
Creating Your Own Personal Card
To create a Personal Card, you need a Card Selector or Card Manager capable of doing that. As of this writing, there are only a few tools that will do this. However, by the time you read this, others might already have the capability.
CardSpace comes installed with Microsoft Vista, and is also installed with the latest version of IE7.
When CardSpace is running, you can create Personal Cards. To run it, either click your favorite Login with InfoCards button, or from the Control Panel (Start | Control Panel | Windows CardSpace).
Choose Add a card, then Create a Personal card. Fill in the information you want, and click Save.
Bandit-Packaged Higgins Native Identity Selector
This selector is currently documented at bandit-project.org/index.php/Identity_Selector_Service, but it is being relocated to wiki.eclipse.org/index.php/I-Card_Selector_Service. When this happens, the eclipse.org site will have both a Java and native code selector. Follow directions at these sites for creating personal cards. Figure 2 shows a screenshot of this selector.
So Mary browses to a car rental Web page (in step 1) and sees a button that lets her reserve her rental with a CardSpace Card. CardSpace Cards are InfoCards. CardSpace happens to be Microsoft’s term for them, and may be the term you encounter on Web pages which are InfoCard-enabled.
Mary clicks the CardSpace button and up pops her Card Selector UI. Her Card Selector displays the cards that will work with the rental site. How did this happen? The Card Selector comes up when the button is pressed because this button is associated with a form which contains a hidden InfoCard token request object. This hidden object contains some criteria, including sets of required and optional claims. These criteria allow the Card Selector to display only the cards which are valid for this site. In this case, the Web site requires a credit card number, driver’s license number, and will optionally accept a phone number and partner affiliations numbers.
Mary scans the list of cards shown by the Card Selector and picks one that happens to be a Managed Card. As we’ve discussed, this card has the address of some Identity Provider, as well as the claims it can provide about Mary. Let’s say this card says it can provide the required claims, as well as Mary’s affiliations (her frequent flyer and hotel affiliation numbers).
With the right Card Selector, you can create your own Personal Card. You can also get a Managed Card from an Identity Provider.
As soon as she selects this card, the Card Selector knows what to do. It knows the Web site really needs a Security Token sent back to it. That Security Token, must come from the Identity Provider pointed to by the card Mary chose. Now, this particular card happens to require that Mary enter her name and password. This is sent to the Identity Provider so it can work on her behalf. Other types of cards are capable of using Personal Cards as the user’s credentials, so no further user interaction is required. After getting Mary’s name and password, the Card Selector performs some WS-* protocol work with the Identity Provider (in step 2) and eventually receives the Security Token which is then returned to the rental Web site (step 3). Yeah, I totally skipped what happens at the Identity Provider. See Anatomy of an Identity Provider to find out what goes on there.
At this point, the Card Selector has done its job and disappears. Mary is returned to her browser where she sees that the card she picked worked, and was used to enter the information needed.
> Is This For Real?
This stuff sounds good in theory. Wouldn’t it be cool if it were all working today? Well it is, and you can try it out right now. Here’s what you’re going to have to do:
- Get yourself set up as an Identity Agent.
- Install an InfoCard.
- Visit an InfoCard-enabled Web site and have fun.
After completing the first step above, we’ll use two Web sites for the other two. One is called Woof, and the other is Wag. While coming up with an open source project name, one of the participants really liked the word FIDO, and the idea of a dog to represent the identity solutions we worked on. The word was cute, fetching even, but somehow unavailable. Maybe remembering Johnny Quest’s dog, someone suggested Bandit instead—and it stuck. To demonstrate InfoCards, we needed a front-end server representing a Service Provider so we named that server woof.bandit-project.org. We also needed a back-end server working as an Identity Provider. Temptation won the day and it got the name wag.bandit-project.org.
What I say about myself tends to be less trusted than what I can get others to say about me— especially when those others are my bank and the government.
Installing a Card Selector
If you have Microsoft Vista or the latest version of IE 7 installed, you’re done. Otherwise the Bandit project provides a nicely packaged native code selector at bandit-project.org/index.php/Identity _Selector_Service. Follow the Download or Build/Test links to get a copy for yourself. As of this writing, an RPM was available but no binary for Windows or Mac OS X was yet available. Those are on the roadmap and might be available by the time you read this.
In addition, there is a Java version hosted at wiki.eclipse.org/index.php/Higgins_Browser_Extension. This requires other components to be previously installed and configured. Maybe the Bandit team will make it downloadable in a simpler form on their site in the future.
Installing an InfoCard
With the right Card Selector, you can create your own Personal Card (See Creating Your Own Personal Card). You can also get a Managed Card from an Identity Provider. Let’s do that now.
Browse to the Identity Provider at wag.bandit-project.org. Before using this server to create a card, you need to create an account (from which the card can be generated). Click the Identity Mgmt tab at the top of the page to create a new account. From there, fill in the form and press the Create button. If successful, you’ll notice this Identity Provider is using LDAP as the backing data store.
Click the InfoCard tab at the top of the page to create a card. Enter the User ID you used when creating an account, and a card name you’ll remember. At this point you can either generate a card that will always ask you for your name and password prior to it being used, or to avoid that, you can go through a few extra steps. If you have a Personal Card (or a Card Selector which can create one), you can enter your new account’s password and check the Use Personal Card For Authentication box. This will bring up your Card Selector which allows you to select (or create, then select) a personal card to be used to authenticate the managed card you’re about to create. In either case, get a Managed Card by clicking the Higgins Card button and download the card from the next page.
Import the card into your Card Selector. This may be as easy as opening the .crd file. If that doesn’t work, look for an Import button in your Card Selector. Once this is done, you’re ready to use it.
Visiting an InfoCard-Enabled Site
Browse to woof.bandit-project.org. You can click the Woof tab at the top of the Wag page to do this. The Woof site is a MedaWiki which allows you to log in with InfoCards. Click log in at the top of the page and notice you have two options—simple and enhanced—to log in with InfoCards. Click the simple option and your Card Selector should appear. Pick the card you imported from the Wag site and send it. If all goes well, you’ll see that the login was successful and your first and last names are used to represent your identity at this site.
As you go through these steps, note that your identity information is not held on your computer; it’s retrieved from wag.bandit-project.org. Even so, you are shown what information is going to be released and you remain in control of whether or not it’s sent.
Other sites also allow you to use your card. Try some of these:
- identityblog.com (click Login)
- pamelaproject.com/testblog (click the pictures—similar to identityblog)
- sxore.com (click Login)
> Cool, now how do I deploy my own?
Most, if not all of the tools and code used to create the Woof and Wag servers are available from the Bandit and Higgins open source projects. The steps required to put everything together is beyond the scope of this article. However, instructions are being documented and updated frequently to make your job of building your own Service Provider or Identity Provider easier. The Bandit project gathers all solutions it provides on the bandit-project.org/index.php/Solutions page. From there, you’ll find a link to an STS solution. That page is http://www.bandit-project.org/index.php/Security_Token_Service . This actually helps you set up an entire Identity Provider, not just the STS (See Anatomy of an Identity Provider). For a backing data store, it uses an LDAP directory.
For help on setting up a Relying Party (InfoCard-enabled) site, be sure to visit the PamelaProject and check out the PamelaWare at pamelaproject.com.
You should now have a basic understanding of what makes up the Identity Metasystem and how InfoCards work. You probably have some ideas as to how you could make use of this new technology, or directions you’d like to see it go. Regardless of what you want to do, the Bandit and Higgins projects are eager to hear about them and help you on your way. Both projects have mailing lists and IRC channels which are almost always monitored. See bandit-project.org/index.php/Communicate and eclipse.org/higgins/getting_started.php for information on how to talk about your ideas and issues. We also try to keep a set of useful CardSpace-related links up to date at http://www.bandit-project.org/index.php/CardSpaceLinks.
Anatomy of an Identity Provider
Figure 3 is a block diagram of what makes up an Identity Provider. Coming into the Identity Provider is WS-Metadata and WS-Trust protocol. (Don't worry about understanding this.) The Identity Provider consists of a Security Token Service (STS) and a way to access identity information. Identity information is gathered using an Identity Attribute Service (IdAS). IdAS is a pluggable component which uses plugins called Context Providers to talk to a number of different types of identity stores such as LDAP directories, SQL databases and address books. Both the STS and IdAS components are well suited for use in other products and solutions as well. They're not just there to build Identity Providers. Among some other things, an Identity Provider performs these tasks:
- STS receives a Request for Security Token (RST)
- STS fetches an identity's information from IdAS
- IdAS uses the appropriate store to get the identity's information.
- STS returns a Request for Security Token Response (RSTR).