转载自：http://xml.coverpages.org/saml.html
Security Assertion Markup Language (SAML)
Overview
The Security Assertion Markup Language (SAML) is being developed by the OASIS XML-Based Security Services Technical Committee (SSTC). The Security Assertion Markup Language (SAML) is "an XML-based framework for exchanging security information. This security information is expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain. A typical example of a subject is a person, identified by his or her email address in a particular Internet DNS domain. Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources. Assertions are represented as XML constructs and have a nested structure, whereby a single assertion might contain several different internal statements about authentication, authorization, and attributes. Note that assertions containing authentication statements merely describe acts of authentication that happened previously. Assertions are issued by SAML authorities, namely, authentication authorities, attribute authorities, and policy decision points. SAML defines a protocol by which clients can request assertions from SAML authorities and get a response from them. This protocol, consisting of XML-based request and response message formats, can be bound to many different underlying communications and transport protocols; SAML currently defines one binding, to SOAP over HTTP. SAML authorities can use various sources of information, such as external policy stores and assertions that were received as input in requests, in creating their responses. Thus, while clients always consume assertions, SAML authorities can be both producers and consumers of assertions." [from the Committee Specification May 2002]
Why SAML?
Why is SAML required? There are four 'drivers' behind the creation of the SAML standard:
Limitations of Browser cookies: Most existing Single-Sign On products use browser cookies to maintain state so that re-authentication is not required. Browser cookies are not transferred between DNS domains. So, if you obtain a cookie from www.abc.com, then that cookie will not be sent in any HTTP messages to www.xyz.com. This could even apply within an organization that has separate DNS domains. Therefore, to solve the Cross-Domain SSO (CDSSO) problem requires the application of different technology. All SSO products solve the CDSSO problem by different techniques.
SSO Interoperability: How products implement SSO and CDSSO are completely proprietary. If you are an organization and you want to perform SSO across different DNS domains within the same organization or you want to perform CDSSO to trading partners, then you will have to use the same SSO product in all the domains.
Web Services: Security within Web Services is still being defined. Most of the focus has been on how to provide confidentiality and authentication/integrity services on an end-to-end basis. The SAML standard provides the means by which authentication and authorization assertions can exchanged between communicating parties.
Federation: The need to simplify identity management across organizational boundaries, allowing users to consolidate many local identities into a single (or at least a reduced set) Federated Identity..." [excerpted from the [URL=http://xml.coverpages.org/SAML-TechOverviewV20-Draft7874.pdf]Security Assertion Markup Language (SAML) 2.0 Technical Overview[/URL], Working Draft 01 22-July-2004.]
[August 19, 2004] [URL=http://xml.coverpages.org/ni2004-08-19-a.html]OASIS Security Services TC Releases Approved SAML 2.0 Committee Drafts for Review.[/URL] Version 2.0 Committee Draft specifications for Security Assertion Markup Language (SAML) have been approved for public review by the OASIS Security Services Technical Committee. SAML (Security Assertion Markup Language) "defines the syntax and processing semantics of assertions made about a subject by a system entity. In the course of making, or relying upon such assertions, SAML system entities may use other protocols to communicate either regarding an assertion itself, or the subject of an assertion. The specification defines both the structure of SAML assertions, and an associated set of protocols, in addition to the processing rules involved in managing a SAML system. SAML assertions and protocol messages are encoded in XML and use XML namespaces." SAML assertions "are typically embedded in other structures for transport, such as HTTP POST requests or XML-encoded SOAP messages. The SAML bindings specification provides frameworks for the embedding and transport of SAML protocol messages. The SAML profiles specification provides a baseline set of profiles for the use of SAML assertions and protocols to accomplish specific use cases or achieve interoperability when using SAML features." The OASIS SAML Version 2.0 effort "addresses issues and enhancement requests that have arisen from experience with real-world SAML implementations and with standards architectures that use SAML, such as the OASIS WSS and XACML work. It adds support for features that were deferred from previous versions of SAML for schedule reasons, such as session support, the exchange of metadata to ensure more interoperable interactions, and collection of credentials. It seeks convergence on a unified technology approach for identity federation by integrating the specifications contributed by the Liberty Alliance." SAML is a flexible and extensible protocol designed to be used by other by other standards.The Liberty Alliance, the Internet2 Shibboleth project, and OASIS Web Services Security (WS-Security) have all adopted SAML as a technological underpinning to varying degrees. Public review of the SAML Version 2.0 Committee Draft documents begins on 2004-08-19 and ends 2004-09-19. Comments may be submitted to the TC using the online comment forms.
[July 15, 2004] [URL=http://xml.coverpages.org/ni2004-07-15-a.html]OASIS Security Services TC Releases SAML 2.0 Documents for Public Review.[/URL] The OASIS Security Services Technical Committee (SSTC) has announced the release of a set of SAML Version 2.0 specifications in advance of TC ballot for approval at Committee Draft level. The Technical Committee is actively soliciting external input on these SAML draft documents; public comment and implementor feedback is invited through August 2, 2004. SAML is an XML framework for exchanging authentication and authorization information. SAML "provides a standard XML schema for specifying authentication, attribute, and authorization decision statements, and it additionally specifies a web services-based request/reply protocol for exchanging these statements." The SAML Version 2.0 review distribution includes five draft specifications and corresponding XML Schemas. Assertions and Protocols defines the syntax and semantics for XML-encoded assertions about authentication, attributes, and authorization, and for the protocols that convey this information. A Bindings specification defines protocol bindings for the use of SAML assertions and request-response messages in communications protocols and frameworks. A SAML 2.0 Profiles draft defines profiles for the use of SAML assertions and request-response messages in communications protocols and frameworks, as well as attribute syntax for use in attribute statements. The Metadata document defines an extensible metadata format for SAML system entities, organized by roles that reflect SAML profiles. Such roles include that of Identity Provider, Service Provider, Affiliation, Attribute Authority, Attribute Requester, and Policy Decision Point. The Authentication Context specification defines a syntax for the definition of authentication context declarations and an initial list of authentication context classes for use with SAML. The OASIS SSTC believes these five key SAML v2.0 specifications are feature-complete, but is prepared to revise the working drafts in response to comments. The SAML v2.0 specification set includes other documents that are non-normative or less crucial for initial implementation. These documents are publicly accessible and will be brought into the formal review process at a later date. Conformance, Security and Privacy Considerations, Baseline Identities and Attributes, Trust Models, SAML V1.x and Liberty ID-FF V1.2 Migration Paths, X.509 Attribute Sharing Profile, Glossary, Implementation Guidelines, Technical Overview, and Executive Overview are among these additional drafts.
In September 2003, OASIS announced the membership approval of SAML Version 1.1 as an OASIS Standard. See the text of the announcement in: [URL=http://xml.coverpages.org/SAMLv11Standard.html]"Security Assertion Markup Language (SAML) Version 1.1 Ratified as OASIS Standard. Baltimore Technologies, BEA Systems, Computer Associates, Entrust, Hewlett-Packard, Netegrity, Oblix, OpenNetwork, Reactivity, RSA Security, SAP, Sun Microsystems, Verisign, and Others Collaborate on Authentication and Authorization."[/URL]
[November 12, 2002] [URL=http://xml.coverpages.org/ni2002-11-12-b.html]Security Assertion Markup Language (SAML) Version 1.0 an OASIS Open Standard.[/URL] The OASIS membership recently voted to approve version 1.0 of the Security Assertion Markup Language (SAML) as an OASIS standard. SAML is "an XML-based framework for Web services that allows the exchange of authentication and authorization information among business partners. SAML enables Web-based security interoperability functions, such as single sign-on, across sites hosted by multiple companies. SAML incorporates industry-standard protocols and messaging frameworks, such as XML Signature, XML Encryption, and SOAP. The specification can be easily integrated in standard environments such as HTTP and standard Web browsers. Likewise, other security environments can use SAML as an authentication and authorization layer. SAML complements Web services standards, such as SOAP, which lack inherent security features. The OASIS Web Services Security Technical Committee, for example, is profiling SAML as one of its set of security tokens."
[April 20, 2002] Committee Specification Level Documents for the Security Assertion Markup Language (SAML). On April 19, 2002 the OASIS XML-Based Security Services Technical Committee (SSTC) released several [URL=http://www.oasis-open.org/committees/security/#documents]SAML specifications[/URL] which have reached 'Committee Specification' maturity level. The TC plans to submit the SAML specification for approval as an OASIS Standard in the July-September 2002 timeframe. The OASIS TC has been chartered to "define an XML framework for exchanging authentication and authorization information" and previously published working drafts for the Security Assertion Markup Language (SAML). Using industry-standard protocols and messaging frameworks, SAML "is an important element in the security technology stack; it makes use of XML digital signatures and XML encryption." In SAML, "security information is expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain. A typical example of a subject is a person, identified by his or her email address in a particular Internet DNS domain. Assertions can convey information about authentication acts performed by subjects, attributes of subjects, and authorization decisions about whether subjects are allowed to access certain resources. Assertions are represented as XML constructs and have a nested structure, whereby a single assertion might contain several different internal statements about authentication, authorization, and attributes." The new Committee Specification deliverables include: (1) SAML Assertions and Protocol, with separate XML Assertion Schema and XML Protocol Schema; (2) SAML Bindings and Profiles; (3) SAML Security and Privacy Considerations [non-normative]; (4) SAML Conformance Program Specification; (5) SAML Glossary. [[URL=http://xml.coverpages.org/ni2002-04-20-a.html]Full context[/URL]]
[June 22, 2001] Security Assertion Markup Language (SAML) is an "XML security standard for exchanging authentication and authorization information." SAML is being developed within the OASIS XML-Based Security Services Technical Committee (SSTC).
[June 22, 2001] SSTC Charter: "The purpose of the XML-Based Security Services TC (SSTC) is to define an XML framework for exchanging authentication and authorization information. The TC will produce set of one or more Committee Specifications that cover use cases and requirements, core assertions, protocols, bindings, and a conformance suite, all of the aforementioned to be examined with respect to security considerations. The work will take the S2ML specification and the intended submission of AuthXML, along with any other relevant and timely submissions, into consideration. The goal (subject to revision) is to publish a substantially complete set of Committee Specifications by 1 June 2001, and submit a Committee Specification to the OASIS membership for its approval by 1 September 2001... The TC has agreed to call its specification Security Assertion Markup Language (SAML, pronounced 'sam-l').
From the Version 0.9 "Security Assertions Markup Language. Core Assertion Architecture" document: "This document contains two sections. Section 1 contains the text proposed by the Core Assertions and Protocol group for the Core Assertions section of the SAML. Section 2 contains references to the material cited in the text. SAML specifies several different types of assertion for different purposes, these are: (1) Authentication Assertion: An authentication assertion asserts that the issuer has authenticated the specified subject. (2) Attribute Assertion: An attribute assertion asserts that the specified subject has the specified attribute(s). Attributes may be specified by means of a URI or through an extension schema that defines structured attributes. (3) Decision Assertion: A decision assertion reports the result of the specified authorization request. (4) Authorization Assertion: An authorization assertion asserts that a subject has been granted specific permissions to access one or more resources. The different types of SAML assertion are encoded in a common XML package, which at a minimum consists of: (1) Basic Information: Each assertion must specify a unique identifier that serves as a name for the assertion. In addition an assertion may specify the date and time of issue and the time interval for which the assertion is valid. (2) Claims: The claims made by the assertion. This document describes the use of assertions to make claims for Authorization and Key Delegation applications. In addition an assertion may contain the following additional elements. An SAML client is not required to support processing of any element contained in an additional element with the sole exception that an SAML client must reject any assertion containing a 'Conditions' element that is not supported. (3) Conditions: The assertion status may be subject to conditions. The status of the assertion might be dependent on additional information from a validation service. The assertion may be dependent on other assertions being valid. The assertion may only be valid if the relying party is a member of a particular audience. (4) Advice: Assertions may contain additional information as advice. The advice element may be used to specify the assertions that were used to make a policy decision. The SAML assertion package is designed to facilitate reuse in other specifications. For this reason XML elements specific to the management of authentication and authorization data are expressed as claims. Possible additional applications of the assertion package format include management of embedded trust roots [XTASS] and authorization policy information [XACML]..."
Principal References
[URL=http://xml.coverpages.org/security.html]"XML and Security"[/URL]: General references
[URL=http://www.oasis-open.org/committees/security/]OASIS Security Services (SAML) TC web site[/URL]
[URL=http://www.oasis-open.org/committees/security/faq.php]SSTC FAQ document[/URL]. "This document helps to answer frequently asked questions about SAML (Security Assertion Markup Language)."
[URL=http://www.oasis-open.org/committees/security/ipr.php]SSTC IPR declarations[/URL]
[URL=http://lists.oasis-open.org/archives/security-services-comment/]SSTC TC comment list archive[/URL]
[URL=http://www.oasis-open.org/committees/security/docs/]SAML document archive[/URL]. See this listing for the most recent document version URLs.
[URL=http://xml.coverpages.org/SAML-TechOverview20v03-11511.pdf]Security Assertion Markup Language (SAML) 2.0 Technical Overview[/URL]. February 20, 2005. [[URL=http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf]source PDF[/URL]]
[URL=http://xml.coverpages.org/SAML-ExecOverviewV206-11785-20050310.pdf]SAML Executive Overview[/URL]. Produced by the OASIS Security Services TC. Revised Version 2.0 Draft. March 10, 2005. [[URL=http://www.oasis-open.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft-06.pdf]source PDF[/URL]]
[URL=http://xml.coverpages.org/SAML-ImplementationGuidelinesV01-8958.pdf]SAML Implementation Guidelines[/URL]. August 27, 2004. [[URL=http://www.oasis-open.org/committees/download.php/8958/sstc-saml-implementation-guidelines-draft-01.pdf]source PDF[/URL]]
Mailing list archives:
[URL=http://lists.oasis-open.org/archives/saml-dev/]SAML-DEV mailing list archives[/URL]
[URL=http://lists.oasis-open.org/archives/security-use/]'security-use' list[/URL]. Use Cases and Requirements
[URL=http://lists.oasis-open.org/archives/security-services/]'security-services' list[/URL]. Main Focus Subcommittee work.
[URL=http://lists.oasis-open.org/archives/security-bindings/]'security-bindings' list[/URL]. Bindings subcommittee.
[URL=http://lists.oasis-open.org/archives/security-conform/]'security-conform' list[/URL]. Conformance subcommittee
[URL=http://lists.oasis-open.org/archives/security-consider/]'security-consider' list[/URL]. Security and Privacy Considerations
Related Activity
[URL=http://xml.coverpages.org/techSociety.html#security]Security, Privacy, and Personalization[/URL]
[URL=http://xml.coverpages.org/libertyAlliance.html]Liberty Alliance Specifications for Federated Network Identification and Authorization[/URL]
[URL=http://www.oasis-open.org/committees/xacml/index.shtml]Extensible Access Control Markup Language (XACML)[/URL]. See the [URL=http://xml.coverpages.org/XACML-PR20010424.html]announcement.[/URL]
[URL=http://xml.coverpages.org/xmlAndEncryption.html]XML and Encryption[/URL]
[URL=http://xml.coverpages.org/xmlSig.html]XML Digital Signature (IETF/W3C)[/URL]
[URL=http://xml.coverpages.org/xkms.html]XML Key Management Specification (XKMS)[/URL]
[URL=http://xml.coverpages.org/s2ml.html]Security Services Markup Language (S2ML)[/URL]
[URL=http://xml.coverpages.org/xacl.html]XML Access Control Language (XACL)[/URL]
[URL=http://xml.coverpages.org/authxml.html]AuthXML Standard for Web Security[/URL]
[URL=http://xml.coverpages.org/idmef.html]Intrusion Detection Message Exchange Format[/URL]
[URL=http://xml.coverpages.org/beep.html]Blocks eXtensible eXchange Protocol Framework (BEEP)[/URL]
[URL=http://middleware.internet2.edu/shibboleth/]Shibboleth[/URL]
News, Specifications, Articles, Commentary
[November 21, 2005] [URL=http://xml.coverpages.org/SAMLv20-Interop200511.html]"Liberty Alliance Announces Latest Companies Passing SAML 2.0 Interoperability Testing. Products from IBM, NEC, NTT and RSA Security Join Liberty's Growing List of Interoperable Identity Solutions."[/URL] - "The Liberty Alliance Project, a global consortium for open federated identity and Web services standards, today announced that products from IBM, NEC, NTT and RSA Security passed interoperability testing at Liberty's recent conformance event. These companies successfully demonstrated that their products meet interoperability standards for Liberty Federation and join nearly seventy other identity products and solutions from multiple vendors that have now passed Liberty interoperability testing. Liberty Alliance holds regular conformance events at varying locations around the world to test products for interoperability of Liberty identity specifications. After participating in a five-day testing event held in Tokyo earlier this month, IBM, NEC, NTT and RSA Security have demonstrated interoperability of products and solutions that incorporate Liberty Federation (Liberty ID-FF 1.2 and/or SAML 2.0) specifications. 'Liberty's Interoperable Program is about creating a global ecosystem of identity solutions that have been proven to work together in an open federated network environment,' said Roger Sullivan, chair of the Liberty Alliance conformance program and vice president of business development for Oracle's Identity Management. 'Since Liberty launched the program in 2003, identity products that have passed interoperability testing have been deployed extensively in a variety of industries and vertical market segments worldwide..."
[November 17, 2005] [URL=http://www.infoworld.com/article/05/11/17/HNmssaml2support_1.html]"Microsoft Says It Won't Support SAML 2.0. Microsoft Backs WS-Federation Protocols for Next Generation of Message-Based Apps."[/URL] By Jeremy Kirk. From [URL=http://www.infoworld.com/]InfoWorld[/URL] (November 17, 2005). "Microsoft will stick by the set of protocols it has picked for identity federation, a concept that includes single sign-on (SSO) for several different Web portals and secure transfers of data between partnered businesses. Microsoft has backed WS-Federation protocols for the next generation of message-based applications because it offers a full suite of security, message, and transaction protocols, said Don Schmidt, senior program manager for Microsoft's Identity and Access group. The company's stance is not about which protocol set is necessarily better but rather which offers a wider flexibility in accommodating federated identity... The WS-Federation protocols compete with the SAML (Security Assertion Markup Language) 2.0 specification, which so far has strong footing in the race to create secured identity federation across organizations. SAML 2.0 is backed by consortiums such as the Liberty Alliance and the Organization for the Advancement of Structured Information Standards (OASIS). SAML 2.0 protocols are fine for strictly Web single sign-on, Schmidt said. But the WS-Federation protocols are better equipped to deal with a distributed Web services environment for message reliability, transaction support and security, he said. SAML 2.0 does not have reliable messaging or transaction support, he said..." See [URL=http://xml.coverpages.org/ni2004-05-26-a.html#microsoftWSFederation]WS-Federation Workshop[/URL]. Note: WS-Federation (July 2003) was not among the specifications presented to the [URL=http://www.oasis-open.org/committees/ws-sx/]OASIS Web Services Secure Exchange (WS-SX) Technical Committee[/URL].
[September 15, 2005] [URL=http://www.infoworld.com/article/05/09/15/HNidfederation_1.html]"Identity Federation: Is it Time to Move Now? Businesses Need a Strong Case to Justify Investing Now, Gartner VP Says."[/URL] By Jeremy Kirk. From [URL=http://www.infoworld.com/]InfoWorld[/URL] (September 15, 2005). "While there is high interest in identity federation, the technology is still in flux and will likely be more expensive and time-consuming to implement immediately rather than three years from now, identity and access management expert [Roy Wagner] said. Most of the current identity federations are based on Web services protocol developed by Liberty Alliance, a consortium of companies working on identity federation, and the Organization for the Advancement of Structure Information Standards. Both have worked together to develop SAML (Security Assertion Markup Language). Another standard (WS-Federation, whose backers include Microsoft) is more general and more flexible but has not been offered to a standards body, Wagner said; he recommends using SAML 2.0, although there have been complaints that the protocols are too specific. Wagner predicts there may be some convergence on a standard, but 'at this point it is not likely to happen in the near future,' he said. The next step, which the technology will catch up soon to, is federated provisioning — combining identities held by a large company such a telecom but stored in several countries."
[September 07, 2005] [URL=http://www.soa-pipeline.com/blog/archives/2005/09/sso_the_holy_gr.html]"SSO: The Holy Grail of SOA."[/URL] By Alice LaPlante. From [URL=http://www.soa-pipeline.com/]SOA Pipeline[/URL] (September 07, 2005). "SAML (Security Assertion Markup Language) was in the spotlight again last week. An XML-based framework developed by OASIS Security Services Technical Committee, SAML allows companies to securely and automatically share identity information on the Web. Computer Associates announced its plans to use SAML 2.0 with eTrust SiteMinder, its Web access management product. The access management support eliminates the need to re-authenticate at each site; the product will thus allow customers to federate as identity providers or as service providers with multiple partners. SAML 2.0 is important because it represents the coming together of two important SSO standards efforts. After all, as recently as this past winter, various groups were working on competing standards, including SAML 1.x, the Liberty Alliance's ID-FF, Internet2's Shibboleth, and Microsoft's Passport. The Liberty Alliance and Internet2 chose to provide input to the latest version of SAML and help consolidate the standards into SAML 2.0..."
[April 15, 2005] [URL=http://www.internetnews.com/dev-news/article.php/3498171]"Liberty Alliance Embraces SAML 2.0."[/URL] By Jim Wagner. From [URL=http://www.internetnews.com/]InternetNews.com[/URL] (April 15, 2005). "With the ink barely dry on the final Security Assertion Markup Language (SAML) 2.0 standard, officials at the Liberty Alliance are set to include the technology in its interoperability test bed Monday. The Liberty Interoperable Logo Program certifies software developers create products that interoperate with products from other vendors using a variety of specified profiles and schema. Officials at OASIS blessed the single sign-on technology for use in the industry Thursday. The technology fills in the gaps left by SAML 1.0, with improved metadata specifications to improve communications between companies using the technology within a federation, as well as new attribute profiles. Roger Sullivan, Liberty Alliance conformance expert group chairman and Oracle vice president for identity management solutions, said the organization has been working on getting SAML 2.0 into the interoperability program for some months... Several vendors have already included SAML 2.0 in their product line or are in the process of rolling out a version in the near future: Oracle, Computer Associates and RSA Security. Sullivan would not say which companies are going through the interoperability process, noting the identities of companies participating in the program are kept secret under non-disclosure agreements until several weeks after successful completion of the program. In order to gain program approval, the product must work with at least two other vendor implementations. The logo is good only for the specific version of the product that undergoes the testing, not the entire product line. According to officials, some 15 vendors and 30 products have already successfully participated in the program, the first in the industry to test and approve interoperability standards for federation, single sign-on and identity-based Web services..."
[March 24, 2005] [URL=http://www.gartner.com/DisplayDocument?doc_cd=126835]"SAML Needs More Than OASIS Approval."[/URL] By Ray Wagner, Charles Abrams, John Pescatore, David Mitchell Smith. Gartner Research Report, ID Number G00126835. March 21, 2005. ['Security Assertion Markup Language (SAML) is now an accepted industry standard. But it will need broad vendor support to deliver real-world business value.'] "OASIS approval [of SAML 2.0 as an OASIS Standard] is a positive step, but much more must be done before SAML can be considered anything more than just another security token format and yet another set of protocols. SAML has been in existence since 2001, and many vendors support it, but very few real-world production applications rely on it. SAML offers enterprises the promise of multivendor interoperability for authentication, authorization and access control products. Real-world business environments need ways to allow a customer to log in at one commerce site and have that customer's authentication and authorization attributes passed on to business partners, without requiring the customer to log in multiple times. This can potentially benefit business by reducing the costs of identity management systems, and by limiting customer abandonment of electronic commerce due to complexity issues. However, for this promise to be realized, all major vendors must support both SAML token formats and SAML protocols organically within their products. This certainly is not yet the case for most of the leading vendors, and not even the vendors that have developed SAML use it within the federation features of their own products. If those vendors did so, major platform vendors would have a much stronger incentive to focus on full SAML support..." Also available in [URL=http://www.gartner.com/resources/126800/126835/saml_needs_more.pdf]PDF[/URL].
[March 10, 2005] [URL=http://xml.coverpages.org/SAML-ExecOverviewV206-11785-20050310.pdf]SAML Executive Overview[/URL]. Produced by members of the OASIS [URL=http://www.oasis-open.org/committees/security/]Security Services (SAML) Technical Committee[/URL]. March 10, 2005. Version 2. draft 6. 5 pages. "SAML, developed by the Security Services Technical Committee of the Organization for the Advancement of Structured Information Standards (OASIS), is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application. SAML is a flexible and extensible protocol designed to be used — and customized if necessary — by other by other standards.The Liberty Alliance, the Internet2 Shibboleth project, and the OASIS Web Services Security (WS-Security) committee have all adopted SAML as a technological underpinning for various purposes. SAML is also supported in major application server products and SAML support is also common among Web services management and security vendors. SAML V2.0 builds on that success. Many of these implementations have demonstrated succcessful interoperability at a series of events — the latest of which was held at the 2005 RSA Conference. The OASIS SAML Interoperability Lab, sponsored by the US Government's GSA, used three separate scenarios to demonstrate SAMLbased interaction between a government or enterprise portal and sites from typical content or service providers. SAML V2.0 unifies the building blocks of federated identity in SAML V1.1 with input from both higher education's Shibboleth initiative and the Liberty Alliance's Identity Federation Framework. As such, SAML V2.0 is a critical step towards full convergence for federated identity standards. XACML (eXtensible Access Control Markup Language) is an XML-based language for access control that has been standardized in OASIS. XACML describes both an access control policy language and a request/response language. The policy language is used to express access control policies ('who can do what when'). The request/response language expresses queries about whether a particular access should be allowed (requests) and describes answers to those queries (responses). The newest versions of XACML and SAML have been designed to complement each other; for example, an XACML policy can specify what a provider should do when it receives a SAML assertion, and XACML-based attributes can be expressed in SAML..." [[URL=http://www.oasis-open.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft-06.pdf]source PDF[/URL]]
[February 16, 2005] [URL=http://xml.coverpages.org/SAML-InteropRSA2005.html]"OASIS Federated Identity Lab Demonstrates SAML 2.0 Interoperability for GSA E-Gov's E-Authentication Initiative. Computer Associates, DataPower Technology, Entrust, Hewlett-Packard Company, Oracle, RSA Security, Sun Microsystems, and Others Showcase Authentication and Authorization Standard at RSA Conference."[/URL] - "Thirteen vendors from around the world teamed with the U.S. General Service Administration (GSA) [URL=http://cio.gov/eauthentication]E-Gov E-Authentication Initiative[/URL] to demonstrate interoperability of the Security Assertion Markup Language (SAML) 2.0, a security specification developed by the OASIS standards consortium. SAML enables secure exchange of authentication, attribute, and authorization information between disparate security domains, making secure Internet e-business transactions possible. The OASIS Federated Identity InterOp Lab, co-sponsored by GSA E-Authentication Initiative, Enspier, and RSA Security, demonstrated a combination of web single sign-on, and single logout scenarios. 'SAML 2.0 brings together SAML 1.x, Liberty Alliance and Shibboleth functionality to provide a logical convergence point for new products and deployments in the coming months,' said Dan Blum, Senior Vice President and Research Director, Burton Group. 'This OASIS InterOp demonstration offers an important proof-of-concept for the new specification.' According to Stephen Timchak, GSA Program Executive, 'The E-Authentication Initiative is committed to helping drive the evolution of federated identity management, and that's why we are excited to sponsor the OASIS Federated Identity InterOp on SAML 2.0 at RSA 2005. I believe that the E-Authentication-sponsored SAML 1.1 interoperability event at last year's RSA conference helped speed the evolution of the SAML standard, and we look forward to being enthusiastic adopters SAML 2.0 when it qualifies for inclusion in the E-Authentication architecture'..."
[February 16, 2005] [URL=http://2005.rsaconference.com/us/general/special.aspx#ofiil]OASIS Federated Identity Interoperability Lab.[/URL] "The OASIS Federated Identity Interoperability Lab will feature companies from around the globe demonstrating interoperability using the OASIS Security Assertion Markup Language Standard (SAML) v2.0 specification. SAML enables secure exchange of authentication, attribute and authorization information between disparate security domains, which makes vendor-independent web single sign-on and secure e-business transactions possible. The Interop Lab will demonstrate vendor interoperability and the practical application of SAML v2.0 technology to solve real-world business problems." Note: The U.S. General Services Administration (GSA) [URL=http://cio.gov/eauthentication/documents/Vendors_SAML2.0.htm]announced[/URL] that the E-Gov E-Authentication Interoperability lab's technical architecture is being expanded to support of a new SAML version 2.0, expected to be ratified as an OASIS Standard. 'Once the SAML 2.0 specification is officially released and is supported in the marketplace by at least 3 interoperable technology products, it is expected to be adopted by E-Authentication; the E-Authentication Interoperability Lab will begin testing products that support the SAML 2.0 specification shortly'..." See the [URL=http://www.oasis-open.org/events/saml-rsa-interop-05-01-04.pdf]OASIS Interop data sheet[/URL].
[January 12, 2005] [URL=http://www.xml.com/pub/a/2005/01/12/saml2.html]"SAML 2: The Building Blocks of Federated Identity."[/URL] By Paul Madsen. From [URL=http://www.xml.com/]XML.com[/URL] (January 12, 2005). "As web services promise to enable integration between business partners through loose-coupling at the application and messaging layer, federation does so at the identity management layer by insulating each domain from the details of the others identity management infrastructure. SAML provides the federated identity building blocks on which other federated architectures can be constructed. With SAML 2.0 now providing a stable and full-featured federated identity security infrastructure, focus can now shift to this work. For instance, the Liberty Alliance's ID-Web Services Framework (Liberty ID-WSF) defines a framework for identity-based web services that leverages the SAML layer. Liberty ID-WSF uses SAML as the mechanism by which the authentication status of a user and the identity and authorizations of web sites can be communicated as part of a SOAP request for some piece of that user's personal information (e.g., their online calendar). Upon ratification as an OASIS Standard, expected in early 2005, SAML 2.0 is expected to become the primary standard for federated identity... SAML defines an XML-based framework for communicating security and identity (e.g., authentication, entitlements, and attribute) information between computing entities. SAML promotes interoperability between disparate security systems, providing the framework for secure e-business transactions across company boundaries. By abstracting away from the particulars of different security infrastructures (e.g., PKI, Kerberos, LDAP, etc), SAML makes possible the dynamic integration necessary in today's constantly changing business environments." See also the [URL=http://xml.coverpages.org/ni2004-08-19-a.html]SAML 2.0 Committee Drafts[/URL].
[December 04, 2004] [URL=http://www.intelligententerprise.com/showArticle.jhtml?articleID=54200324]"SAML: The Secret to Centralized Identity Management."[/URL] By Hank Simon. From [URL=http://www.intelligententerprise.com/]Intelligent Enterprise[/URL] (December 04, 2004). ['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?'] "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. 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..."
[December 02, 2004] [URL=http://xml.coverpages.org/WSS-SAML-TProfileCD04-9749.pdf]Web Services Security: SAML Token Profile[/URL]. Committee Draft, approved as an OASIS Standard. Reference: October 21, 2004. Edited by Phillip Hallam-Baker (VeriSign), Chris Kaler (Microsoft), Ronald Monzillo (Sun), and Anthony Nadalin (IBM). 31 pages. The WSS SAML Token Profile approved as an OASIS Standard describes how to use Security Assertion Markup Language (SAML) Version 1.1 assertions with the Web Services Security (WSS): SOAP Message Security specification. It defines how SAML assertions are carried in and referenced from <wsse:security> headers and describes how SAML assertions are used with XML Signature to bind the statements of the assertions (i.e., the claims) to a SOAP message. [[URL=http://www.oasis-open.org/committees/download.php/9749/wss-saml-token-profile-1.0-cd-04.pdf]source PDF[/URL]]
[November 01, 2004] [URL=http://xml.coverpages.org/draft-tschofenig-sip-saml-01.txt]"Using SAML for SIP."[/URL] By [URL=mailto:Hannes.Tschofenig@siemens.com]Hannes Tschofenig[/URL] (Siemens), [URL=mailto:jon.peterson@neustar.biz]Jon Peterson[/URL] (NeuStar, Inc), [URL=mailto:jmpolk@cisco.com]James Polk[/URL] (Cisco), [URL=mailto:douglas.sicker@colorado.edu]Douglas C. Sicker[/URL] (University of Colorado at Boulder), and Marcus Tegnander (Siemens). IETF SIP Working Group. Internet Draft. Reference: 'draft-tschofenig-sip-saml-01.txt' October 25, 2004, expires: April 25, 2005. 36 pages. IETF ephemeral source URL: http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-01.txt. Previous version: [URL=http://xml.coverpages.org/draft-tschofenig-sip-saml-00.txt]http://xml.coverpages.org/draft-tschofenig-sip-saml-00.txt[/URL]. ['This document describes how to use the Security Assertion Markup Language (SAML) to offer trait-based authorization. As such, it provides an alternative to existing authorization mechanisms for SIP.'] "This document proposes a method for using the Security Assertion Markup Language (SAML) in collaboration with SIP to acommodate richer authorization mechanisms and enable trait-based authorization where you are authenticated using roles or traits instead of identity. A motivation for trait based authorization and some scenarios are presented in J. Peterson, "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)." Security Assertion Markup Language (SAML) is an XML [language] for security information exchange that is being developed by OASIS. SAML enables users to gain access to multiple website resources without having to re-authenticate every time the domain changes. The first authentication would be transferred to subsequent domains using SAML. To provide trait-based authorization a few solutions are possible: authorization certificates, SPKI or extensions to the authenticated identity body (J. Peterson, "SIP Authenticated Identity Body (AIB) Format"). The authors selected SAML due to the amount of work done in the area of SAML which provides some assurance that this technology is mature enough..."
[June 29, 2004] [URL=http://www.crn.com/sections/breakingnews/breakingnews.jhtml?articleId=22102766]"McNealy: Sun, Microsoft To Unveil Phase One of Partnership in Late Summer. Directory Interoperability for Single Sign-On Will Be Tackled First."[/URL] By [URL=mailto:emontalb@cmp.com]Elizabeth Montalbano[/URL]. In [URL=http://www.crn.com/]CRN[/URL] (June 29, 2004). "Sun and Microsoft plan to detail Phase One of their historic partnership in late summer, Sun Chairman and CEO Scott McNealy said Tuesday at JavaOne. The first phase of the partnership will be to 'solve single sign-on' and facilitate interoperability between the LDAP model of the directory and identity management products in Sun's Java Enterprise System and Microsoft ActiveDirectory, McNealy told attendees in his morning keynote at Sun's annual Java developer confab in San Francisco. Once Sun and Microsoft make their software interoperable, 'users can log into the network once without having to remember multiple passwords and have their authentication travel across software infrastructure from both Sun and Microsoft,' McNealy said. Applications that run on both systems also can take advantage of the same infrastructure for network identity. 'This should make for more efficient consumer and enterprise use,' he said. Enabling single sign-on for users across multiple Web sites, particularly for e-commerce users, has been a tricky issue. Sun and a group of partner companies initiated and supported the Liberty Alliance, which leverages the Security Assertion Markup Language (SAML) specification to enable single sign-on, while Microsoft for a time planned its own project, HailStorm, to collect user information and authenticate users across multiple sites. But users were uncomfortable with the idea of Microsoft owning all of their personal information, so HailStorm didn't fly as expected..."
[June 16, 2004] [URL=http://xml.coverpages.org/draft-hodges-saml-mediatype-00.txt]"application/saml+xml Media Type Registration."[/URL] By [URL=mailto:jeff.hodges@sun.com]Jeff Hodges[/URL] (Sun Microsystems). IETF Network Working Group. Internet Draft. Reference: 'draft-hodges-saml-mediatype-00'. June 13, 2004, expires December 12, 2004. "The SAML specification sets, SAML V1.0 and SAML V1.1, are work products of the OASIS Security Services Technical Committee (SSTC). The SAML specifications define XML-based constructs with which one may make, and convey, security assertions. For example, one can assert that an authentication event pertaining to some subject has occured and convey said assertion to a relying party. This document defines a MIME media type 'application/saml+xml' for use with the XML serialization of SAML (Security Assertion Markup Language) assertions, or other SAML-defined objects..."
[June 10, 2004] [URL=http://techupdate.zdnet.com/techupdate/stories/main/Federation_acceleration.html]"Federation Acceleration."[/URL] By [URL=mailto:Dan.Farber@cnet.com]Dan Farber[/URL]. In [URL=http://techupdate.zdnet.com/]ZDNet Tech Update[/URL] (June 08, 2004). "Federated identity is beginning to gain some traction among corporations, according to a survey conducted by Ping Identity, a provider of federated identity management solutions and the founding sponsor of SourceID, an open source community focused on federation efforts, such as SAML, Liberty Alliance and WS-Federation. The survey, gleaned from nearly 100 responses by registered downloaders of SourceID, showed a strong increase of federations in production, rising from 1 percent to 7 percent between the first and second quarters of this year. Over 50 percent of those surveyed thought they would engage in between 1 and 3 federations within the next 24 months. Only 6 percent surveyed anticipated participation in more than 10 federations in the same period. Ease-of-integration and vendor interoperability were cited as the most important characteristics of federation products, with single-sign on (SSO) amongst partners cited as the primary use case desired. Currently, SAML 1.1 is the dominant protocol used for federation. Vendors have announced support for the Liberty Alliance Liberty ID-FF 1.1, but few are shipping in a substantial way, according to Eric Norlin, senior vice president of marketing at Ping Identity. The survey indicated that interest in SAML 2.0 and WS Federation will begin to ramp up significantly in the latter part of 2004 and continue throughout 2005..."
[February 19, 2004] [URL=http://xml.coverpages.org/ni2004-02-19-a.html]OASIS SAML Interoperability Event Demonstrates Single Sign-On at RSA Conference.[/URL] OASIS has announced that several vendors will team with the U.S. General Service Administration E-Gov E-Authentication Initiative at the RSA Conference 2004 to demonstrate interoperability of the Security Assertion Markup Language (SAML). Vendor participants include Computer Associates, DataPower Technology, Entrust, Hewlett-Packard, Oblix, OpenNetwork, RSA Security, Sun Microsystems, and others. SAML Version 1.1 is an OASIS authentication and authorization standard based upon an XML framework for exchanging security information. "This security information is expressed in the form of assertions about subjects, where a subject is an entity (either human or computer) that has an identity in some security domain. A typical example of a subject is a person, identified by his or her email address in a particular Internet DNS domain. One major design goal for SAML is Single Sign-On (SSO), the ability of a user to authenticate in one domain and use resources in other domains without re-authenticating." The unique teaming of the U.U. General Service Administration with eleven vendors in this RSA event "showcases interoperability across three separate scenarios, simulating interaction between a government or enterprise portal and sites from typical content or service providers. For the first time ever, members of the OASIS Security Services Technical Committee will demonstrate both types of SAML version 1.1 Single Sign-On, along with additional scenarios that highlight SAML's flexibility. The event is sponsored by the U.S. GSA E-Gov E-Authentication Initiative, which is committed to delivering open standards-based authentication solutions to U.S. government agencies." In connection with the OASIS SAML 1.1 Interoperability Showcase, members of the Security Services TC have published a Technical Overview of the OASIS Security Assertion Markup Language (SAML) V1.1 as a committee working draft.
[Febuary 20, 2004] [URL=http://xml.coverpages.org/SAML-RSA.html]"Netegrity to Discuss Next Generation of SAML at RSA Conference."[/URL] - "[URL=http://www.netegrity.com/]Netegrity, Inc.[/URL], a leading provider of identity and access management solutions, today announced that Prateek Mishra, Director of Technology and Architecture at Netegrity and co-chair of the OASIS SAML Committee, will deliver a presentation at the RSA Conference discussing the next version of SAML (Security Assertion Markup Language). Mishra's presentation titled 'SAML 2.0: Unified Foundation for Federated Security' will be presented as part of the RSA Conference Standards Track on Tuesday, February 24th at 4:15 pm PT. Netegrity will also be [URL=http://2004.rsaconference.com/exhibitor-list.aspx]exhibiting[/URL] at the RSA Conference (Booth #1421) where the company will showcase its identity and access management solutions, including Netegrity's provisioning solution, Netegrity IdentityMinder eProvision. Mishra's presentation will discuss the new features of SAML 2.0 and how it brings together disparate efforts in order to create a single federated security umbrella. SAML 2.0 will build upon SAML 1.0 deployments and integrate with the enhanced functionality of the Liberty ID-FF (Identity Federation Framework) layers. In addition, Mishra will discuss the relationship between SAML 2.0 and other proposed standards, such as WS-Security, and how they jointly provide organizations with a trusted model to enable secure Web services and federation. Netegrity was one of the original creators of the SAML specification and over the last three years has helped to drive industry adoption of SAML, including support for the SAML standard within both the Netegrity SiteMinder Web access management product and the Netegrity TransactionMinder Web services security product. The company also recently shipped Netegrity SiteMinder 6.0 which provides advanced federated security capabilities through enhanced support for SAML..."
[January 23, 2004] [URL=http://www.nwfusion.com/newsletters/dir/2004/0119id1.html]"SAML Tops Federation Projects Survey."[/URL] By Dave Kearns. In [URL=http://www.nwfusion.com/]Network World[/URL] (January 09, 2004). Ping Identity, sponsor of the SourceID Web site, recently surveyed folks who downloaded its open-source Liberty Alliance tool kit. "When asked about the priority of federation protocols, it wasn't surprising that the Liberty Alliance protocols out-polled the WS-Federation protocol (favored by IBM and Microsoft) since the respondents were specifically those who downloaded a Liberty Alliance tool kit. But even adding together those who preferred Liberty phase II with those who preferred Liberty phase I (a total of 42% of the respondents) they were still outweighed (at 49%) by those who favored Versions 1.0, 1.1 and 2.0 of the Security Assertion Markup Language (SAML). SAML is the transport mechanism for the Liberty Alliance proposals, and one of the allowed transports for WS-Federation, but it appears that a number of projects are working directly with SAML and by-passing the 'higher' layers of the two competing standards. It might be that the projects being talked about are all early stage developments, with the SAML parts being worked on now while the developers look to see which of the two competing standards will emerge with an edge -- or, perhaps, a consolidation or merger might occur with one standard being created from the two we currently have. If you think that's a likely scenario, then it would be wise to put off any development at that upper level until the parameters of the eventual standard begin to take shape. Another of the survey questions asked downloaders what additional protocols were 'of interest' to them vis-à-vis federation. The big winner there was OASIS' Extensible Access Control Markup Language (XACML), with 49%, followed by Service Provisioning Markup Language (SPML) at 29%, and eXtensible Resource Identifier (XRI) with 14%. A scattering of other protocols took 8% of the responses. XRI could be considered a competitor to Universal Description, Discovery and Integration..." See also: (1) [URL=http://xml.coverpages.org/xacml.html]"Extensible Access Control Markup Language (XACML)"[/URL]; (2) [URL=http://xml.coverpages.org/provisioningServices.html]"XML-Based Provisioning Services"[/URL]; (3) [URL=http://xml.coverpages.org/ni2004-01-19-a.html]"OASIS TC Promotes Extensible Resource Identifier (XRI) Specification."[/URL]
[December 16, 2003] [URL=http://www.acsac.org/2003/papers/73.pdf]"Security Analysis of the SAML Single Sign-on Browser/Artifact Profile."[/URL] By [URL=mailto:tgr@zurich.ibm.com]Thomas Gross[/URL] (IBM Zurich Research Laboratory). Paper presented Thursday, December 11, 2003 at the 19th Annual Computer Security Applications Conference (December 8-12, 2003, Las Vegas, Nevada, USA). With 21 references. "Many influential industrial players are currently pursuing the development of new protocols for federated identity management. The Security Assertion Markup Language (SAML) is an important standardized example of this new protocol class and will be widely used in business-to-business scenarios to reduce user-management costs. SAML utilizes a constraintbased specification that is a popular design technique of this protocol class. It does not include a general security analysis, but provides an attack-by-attack list of countermeasures as security consideration. We present a security analysis of the SAML Single Sign-on Browser/Artifact profile, which is the first one for such a protocol standard. Our analysis of the protocol design reveals several flaws in the specification that can lead to vulnerable implementations. To demonstrate their impact, we exploit some of these flaws to mount attacks on the protocol... We have deduced several recommendations for the design of browser-based protocols from our analysis. First of all, we strongly recommend that secure channels such as SSL 3.0 or TLS 1.0 with unilateral authentication for message transfer always be used. They outmatch normal transfer of signed and encrypted messages, as they provide authentication, freshness, and replay prevention. We also recommend including more explicitness measures into the messages. It is important to name protocol type, protocol step, source and destination of a message explicitly in the message. Such measures could for instance prevent attacks where multiple services of a site are involved.We recommend not only considering successful protocol runs, but also analyzing all states the protocol can reach. Especially error states may hide opportunities for attacks such as our referrer attack. We are convinced that the SAML Single Sign-on Browser/Artifact profile is in general a well-written protocol. In fact, it is one of the most carefully designed browser-based protocols in federated identity management. Nevertheless, several changes are required to improve its security and prepare for its broad application in industry..." [[URL=http://xml.coverpages.org/GrossACSAC2003.pdf]cache[/URL]]
[October 20, 2003] [URL=http://www.eweek.com/article2/0,4149,1362610,00.asp]"Navy Deploying Its Battle Plan: SAML."[/URL] By [URL=mailto:anne_chen@ziffdavis.com]Anne Chen[/URL]. In [URL=http://www.eweek.com/]eWEEK[/URL] (October 20, 2003). "At the U.S. Navy's Space and Naval Warfare Systems Command, the battle plans to gain control of an it environment with an estimated 200,000 applications center on single-sign-on capabilities and the use of SAML... In 2001, Adm. William Fallon, vice chief of naval operations, created Task Force Web, an initiative to winnow the Navy's thousands of legacy applications. The program called for all Navy applications to be Web-enabled by next year and available to some 720,000 Navy users via the Navy Enterprise Portal. The task proved to be much larger than anyone thought. At the time, the Navy had about 200,000 applications in use, many of which were deployed at the department level and overlapped with those in other Navy units. To control that environment, the Navy decided to deploy a portal based on a Web services architecture. It was decided the portal would be based on open standards, so the Navy chose to build its Web services architecture using the J2EE (Java 2 Platform, Enterprise Edition) environment. The Navy spent about $1 million to develop internally a middleware layer that enables the agency to substitute standards or data definitions without forcing changes to user services or underlying databases. This portal connector links the Navy's disparate legacy applications and Web services... SPAWAR -- which acquires and deploys the technology used in ships and airplanes, as well as in network operating centers in the continental United States and overseas -- decided single sign-on would be the most effective way to handle identity management for users to access the Navy Enterprise Portal... Because of the Navy's need to support personnel and contractors stationed around the globe, SPAWAR chose to support single-sign-on capabilities that are managed as a reusable Web service. For identity management authorization, SPAWAR decided to use open standards, including SAML; XML; Simple Object Access Protocol; and Universal Description, Discovery and Integration. This led to the Navy's decision earlier this year to pilot Oblix Inc.'s NetPoint Identity Management and Access Control Solution 6.1 because Oblix supports SAML... In the initial phase of the program, SPAWAR deployed NetPoint to handle SAML-enabled, single-sign-on authentication of 5,500 users aboard the battleship USS Teddy Roosevelt, enabling them to access applications that do everything from tracking parts to pinpointing the location of enemy vessels. NetPoint handles the exchange of SAML security assertions between users on the ship and servers onshore, and it automatically logs users in to the Navy Enterprise Portal and its available applications. The deployment of the project was successful enough that the Navy is planning to use NetPoint to provide single-sign-on capabilities to all 720,000 naval users and civilian contractors who access the Navy Marine Corps Intranet. Eventually, that number could reach as high as 3 million because all users associated with the Navy will be able to have their identity managed this way..."
[返回] 中文XML论坛 - 专业的XML技术讨论区 →
XML.ORG.CN讨论区 - 高级XML应用 → 『 XML安全 』 → [推荐] SAML介绍 及 资料汇总
(订阅本版)
2005/12/6 10:09:00
新浪微博
[推荐] SAML介绍 及 资料汇总
