SAML: The master key?
Cover story: GSA pushes the identity protocol for sharing credentials across organizational lines
- By Joab Jackson
- Jan 18, 2008
Citizen Joe wants to do some retirement planning. So he logs in to his Fidelity account, where he can do the usual investment planning stuff, such as changing the ratio of his stock funds. But, with a click, he also can check on his information held in Social Security Administration databases.
Five years ago, when Joe wanted to access this information, he would have had to open a new browser window and log in directly to the SSA site. But now SSA trusts that a log-in request coming from the Fidelity servers is just as good as a password from Joe himself.
Welcome to the world of federated identity management. Imagine a day when instead of setting up an account with each organization you do business with, you set up a single account, which all the parties can consult.
Such a setup could be useful for federal agencies for a number of reasons. For one, federal employees often need to access systems and data held by agencies other than their own. For another, e-government initiatives involve people who often hold no government-recognized credentials. How does the government authenticate their identities? The General Services Administration's E-Authentication Identity Federation initiative can meet these needs, said David Temoshok, director of identity policy and management at GSA's Office of Governmentwide Policy. The program is a central hub for facilitating interactions among different organizations.
And one of the ways E-Authentication can offer this service is through an emerging Extensible Markup Language-based standard, called the Security Assertion Markup Language (SAML), which was first developed by the Organization for the Advancement of Structured Information Standards and later adopted by the Liberty Alliance as the backbone for its efforts to offer tools for federated network identity.
'These assertions help downstream when a provider wants to evaluate whether or not this particular identity can access its service,' said Eric Yuan, senior system architect at Booz Allen Hamilton, who helped implement SAML as part of the Defense Information Systems Agency's Network-Centric Enterprise Services program. 'They can take the attributes as trusted information to make that access-control policy decision.'
As agencies increasingly work with outside parties, a federated approach makes sense. 'I don't have to manage people who shouldn't necessarily be in my directory, meaning I don't have to pay for the management of passwords [for people] who aren't working for my organization,' said Northrop Grumman systems engineer Erik Bowman.The GSA advantage
Of course, when it comes to matters of electronic identification, most agencies rely on the standards set by Homeland Security Presidential Directive 12, which provides a secure and standardized way for identifying government employees.
But even though HSPD-12 can offer a foolproof way of simply identifying a person for online activities, agencies also need a way to share more information than just the person's identity. Perhaps an agency wants to grant an individual access to a protected resource and needs qualifications of some sort, in addition to standard authentication, to verify suitability.
This is where GSA's E-Authentication program comes in. It relies on Version 2.0 of SAML, which allows systems to attach additional attribute information ' such as certificates, licenses, training, level of education and privileges ' to an identity assertion.
'Attribute information is built into the SAML standards,' Temoshok said. 'Therefore, the SAML infrastructure that we've built for E-Authentication will allow identity assertions to include attribute information.'
GSA's E-Authentication system acts as a broker among different agencies and for nongovernmental organizations doing business with the government. Agencies join the system and use the guidelines, policies and tags supplied by GSA to share common terminology and operating procedures for identity assertions.
Each time an agency sends a SAML assertion for authentication to another system, it goes through the GSA network, which acts as a broker.
GSA adopted a credential system with four levels of credentials developed by the National Institute of Standards and Technology. The levels are based on how rigorous a credential provider's authentication process is, the fourth being the most stringent. This allows an agency to accept the credentials of another party whose authentication process is at about the same level as its own, said Matthew Gardiner, senior product marketing manager at CA.
Through the Liberty Alliance, GSA also maintains a list of SAML-based products that are interoperable. Like the common terminology, this streamlines the process of setting up an authenticating relationship with another party. In September, GSA mandated that all products undergoing SAML interoperability testing be certified to be interoperable with Version 2.0 of SAML.
'We do testing to ensure all the products work with our interface specification in an interoperable way,' Temoshok said. 'So agencies can choose the software that best meets their needs with the assurance that it will be interoperable with the rest of federal government.'
More than 70 agency programs participate, including the Commerce Department's Export.gov, the Defense Department's MyPay and the Office of Personnel Management's Electronic Official Personnel Folder. 'We're performing online transactions for these applications today,' Temoshok said.How it works
In a typical SAML scenario, there are two parties: an identity provider (the agency issuing the credentials) and an identity consumer (the agency with the service being accessed).
In a federated model, a broker acts as the common point of contact between the consumer and provider.
'The SAML assertion is just a little packet of identity information that is signed,' said Eve Maler, a principal engineer at Sun Microsystems and one of the people behind the development of SAML. 'It may have additional information about how the user was authenticated, by password or smart card or something. And then the service provider is in the position of taking a look at the assertion, validating [it] and deciding whether they will accept the information.'
A SAML assertion will have three statements: the authentication statement, an attribute statement and, in some cases, a simple authorization decision, which is an approval to use the system in question. The latter is not commonly used and can be handled in far greater detail by another XML-based standard called Extensible Access Control Markup Language, or XACML. It could also have additional information, such as the time frame for which the assertion is good.
In most cases, SAML assertions are conveyed via the HTTP post command. An example: An employee of Agency A logs into Agency A's Web portal, which has links to partner sites. The user clicks a link to an outside resource, and the portal server sends a SAML assertion to the outside service provider. The user's browser is redirected to the second site without the user having to log in again.
Of course, the simplicity of this authorization depends on all parties agreeing beforehand on levels of authorization ' or they rely on a third party, such as GSA.
Version 2.0 of SAML also allows the additional capability of having Agency B further check into the credentials issued by Agency A. This would come in handy when the visiting party wants access to additional resources or when a user wants to go directly to the outside resource without having to go through the portal first.Product implementation
So how does one get started using SAML on a systems administration level? Fortunately, most access management software can do the job with some configuration or an upgrade.
Most e-commerce-based Web sites run some form of access management software, which executes tasks such as checking credentials, running policy and auditing user actions. This is the software that allows users to log on to a site once and run multiple applications on that site without logging in to each one.
'What most agencies do is take their access management system and they federation-enable it,' Gardiner said. For instance, CA's SiteMinder access management system offers federation as a service. This simply means that in addition to logging on users directly, it can also accept SAML packets from trusted parties as a form of authentication. Administrators would have to choose to activate SAML acceptance and choose SAML 1.1 or 2.0.
SAML can also be activated at the hardware level. Juniper Networks' Virtual Private Networking appliances can produce and digest SAML 1.1 assertions, said Rich Campagna, product line manager at Juniper. Someone can access a back-end application on the private network without being challenged for log-in information again, as long as a SAML assertion is presented by the user's home system.
Setting up a SAML authentication service on Juniper VPN appliances is basically like setting up any other authentication process, Campagna said. The systems administrator would identify the trusted partners and establish the specific conditions of accepting their tokens as valid. To establish the hardware as a SAML token provider, the administrator would identify the applications on the network that will accept SAML credentials.
'The administrator logs on to the user interface, creates [a link to] the application and attaches groups of users to that application,' Campagna said. 'So when a user logs in, they will see a link to that application.'
With the hardware, software and ' thanks to GSA ' policies, federal agencies can start to streamline their cross-agency authentication processes.
'Usually, you don't see the federal government being very early in something,' Gardiner said. 'But GSA was extremely early to federated identity, and I think they should get credit for it. They are taking a newly invented concept and applying it to the federal government in a very massive way.'