SAML: The Secret to Centralized Identity Management
Complicated by too many systems, too many applications, and too many passwords, identity management is a major headache for most organizations. Can an intelligent, Web-services approach employing new standards ride to the rescue?
The last time some of our internal users and external partners counted, they had more than 15 passwords they had to keep track of. Of course, they could keep all those 15 passwords in their heads. Yeah, right! Every time they needed new access to a new resource, application, or data set, they had to find the responsible administrators. And the administrators were always available, never on vacation, and always had a backup admin. Yeah, right! And when users left the company or were terminated, or when partners became competitors, the administrators were always informed so that they could disable access. Yeah, right! And in this dream world, we know that the CIOs were happy and always received compliments from the user community on the ease of getting to the data. Yeah, double right!
The term that covers many of these issues is called identity management, and the CIO asked my team to look into the situation to see if we could improve it.
Identity management refers to provisioning, password management, and access control. Typically, access rights are stored in different locations, with separate access-control lists for individual applications and resources. Identity management must control data, people, and resources that are distributed across different locations. Historically, a multitude of separate systems handle identity management functions. For example, one program handles provisioning, another manages passwords, LDAP stores authentication information, and each application (or administrator) maintains individual user access-control lists. Keeping these separate functions maintained, synchronized, and up to date is a resource-intensive, costly proposition.
We've developed an authentication/authorization (AA) Web service that unifies the functions of identity management as a first step toward the goal of a federated, enterprisewide, single sign-on solution that improves our identity management problem. This AA Web service is a multistage set of services that enables a user to login once and then invoke a Web service to access applications and data resources. This approach has two major benefits. First, it assists in the simplification of identity management by transferring access-control management from multiple, local applications to a centralized authority, such as LDAP. Second, this approach provides a general method to allow Web services to gain access to data.
Centralization is Key
We used LDAP as our centralized authority by adopting a rules engine by Jericho Systems, a software solutions company that has developed a security package called EnterSpace. EnterSpace includes a SAML service and the rules engine as one component of the security package. We selected Jericho Systems because the company offered a good product, a good price, and it was willing to work with our constraints. An advantage of EnterSpace is that you can use SAML with the rules engine and customizable rules to link all components of identity management to LDAP as a centralized authority.
Centralizing and linking provisioning, password management, and access control makes life simpler. It's natural to link identity management processes to LDAP, as a reference point and central authority. However, LDAP is typically used for authentication, not for authorization. SAML facilitates our ability to link LDAP authentication with access authorization.
In November 2002, the Organization for Advancement of Structured Information Standards (OASIS) ratified SAML as the eXtensible Markup Language (XML) framework for exchanging authentication and authorization information among business partners, particularly through Web services. SAML enables Web-based security interoperability functions, such as single sign-on, across sites that are hosted by multiple companies.
SAML supports secure interchange of authentication and authorization information by leveraging the core Web services standards of XML, Simple Object Access Protocol (SOAP), and Transport Layer Security (TLS). Many vendors, such as RSA, Netegrity, IBM, Oracle, BEA, Oblix, and Jericho have committed to SAML and are implementing the specification in their products.
A SAML assertion uses the header in a SOAP message to pass though HTTP, transferring security information between an assertion authority and a relaying party.
For example, a user can login at one site; a SAML assertion transfers the user authentication token; and the transferred token provides authentication to a remote site. A SAML package can include the authentication token as well as user attributes that can be tested against the rules engine for authorization and access control.
It's important to note that SAML doesn't perform the authentication; rather, it transports the authentication information. In addition, SAML can use different authentication authorities, such as LDAP, Active Directory, and Radius, allowing for different identification methods such as password, biometric, Public Key Infrastructure (PKI), Secure Socket Layer (SSL), Kerberos, and so on. Then, as the transport, SAML passes the assertion information that the user is authenticated. In contrast, SAML doesn't perform authorization or transport access-control information.
Picture SAML as a door with a bouncer, as you might see in the movies. If some shady figure comes up and says "Joe sent me," that means that Joe authenticated the speaker and the bouncer can direct the person to the local poker game. If a glamorous actress appears and says "Rudolph sent me," the bouncer reviews Rudolph's access list of VIPs, locates her name, and then escorts her to see the show. Finally, if James Bond flashes a card and looks into a scanner, he may be authenticated by the card and a retina scan. Then the authentication information is compared to an authorization list that identifies agents who are allowed to enter the secret elevator to see Q.
SAML Security Risks
SAML has three well-understood potential security attacks:
Replay attack, which occurs when a malicious hacker hijacks a SAML token and replays it to gain illicit access
DNS spoofing, which occurs when a hacker intercepts a SAML token and sends a false DNS address
HTTP Referrer Attack, which occurs when a hacker tries to reuse an HTTP referrer tag.
Using a timed session can reduce or eliminate the threat of these three attacks. Eliminating the attacks is done by using a token only once and logging the use so that reuse is flagged; by using an IP address to avoid DNS spoofing; and by using HTTPS with SSL/TLS to eliminate an HTTP attack. Experts and analysts agree that these risks can be mitigated and that SAML offers a secure standard for assertion.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.