Introduction to SAML: Securely sharing digital identity information

Brief introduction

Security is an important factor to consider for all Web projects at design time. Whether you choose the shortest password, decide when to use SSL to encrypt an HTTP session, or identify users by using an automatic logon cookie, you often have a significant design effort to protect the user's identity and other information they may have on the Web site. Bad security can lead to PR disasters. When end users struggle to keep control of their personal information, they face a confusing privacy policy, and they need to keep in mind the different passwords of many sites and the "phishing" events.

At the macro level, digital identity has caused many complex technical and social problems, and some industry groups such as Liberty Alliance and Identitygang are trying to solve them by developing new technical standards. On a smaller scale, you can use tools to provide better security for your users. Please consider password management issues. Users who visit their Web sites to save their personal data must be authenticated before they can access their data. Authenticate users by verifying that they are the claimed users. The easiest way to authenticate is to use a password. However, if each site needs its own set of passwords, users will have a large number of passwords that are difficult to control. Microsoft first tried to provide a global solution to the problem through its Passport Network in 1998. Passport makes it possible for any Web site to use personal data (such as user name, address, credit card number) that the user submits to Passport. Passport is the first e-commerce attempt in single sign-on (Sign-on,sso). It was not popular, in part because of concerns about the system's closeness. However, the concept of SSO is compelling, with many open standards and business plans following passport. With SSO, a Web site can share user identity information with other sites.

SSO is particularly useful for businesses that use Application Service provider (application service provider,asp) software services. The ASP hosts the application on its own server and sells its access as a service. The company can manage its own users and passwords in its standard directory servers, and then grant users access to the ASP application through SSO. SSO allows companies to manage their own users ' information without having to maintain multiple user accounts for each employee. For users, the advantage of SSO is that they can use a username and password in multiple applications, and there is no need to validate the switch between applications. SSO is not only for Web applications, it can be used for any type of application, as long as there is a protocol that securely transmits identity information. The open standard for this type of communication is the Security Assertion Markup Language (SAML).

About SAML

SAML provides a secure protocol for SSO. SAML (read as "Sam-ell") is a specification that allows Web sites to securely share identity information from International Alliance OASIS, which is behind ebXML and other XML standards. The site uses the SAML XML Glossary and request/Answer mode to exchange identity information over HTTP. This standardization of information sharing can help the Web site integrate with multiple partners and avoid controversy over the design and maintenance of proprietary integrated channels for different partners. SAML1.0 was unveiled in November 2002. This article describes the SAML1.1, which was finally completed in 2003. Although SAML 2.0, which was completed in 2005, introduced some important new features of the Support Identity Federation, the BEA WebLogic Server 9.x supports SAML1.1, so this article focuses on SAML1.1.

A basic example of SAML

Let's look at a very basic example of SAML. As the name suggests, the core element of SAML is the security assertion. Assertion is a statement that requires no proof. A security assertion is a statement about a user's identity and can only be supported by receiving a site trust that asserts the publisher. In Saml, the site where the assertion is published is called "publisher," "Assert party," or "source site." Sites that receive assertions and trust them are called "trusted parties" or "target sites."

In this example scenario, the user logs on to the source site using the username and password. The user then wants to access the target site without having to authenticate again. Figure 1 shows the interaction between the source site and the target site to enable users to access both sites via a single sign-on.

Figure 1: A SAML sample Scenario