Summary:
SAML and XACML play different roles in XML-based security certification systems, but it is equally important. Design permission access control services, especially the unified security access control of cross-organization, cross-domain, and cross-use system, can not understand SAML.
Saml overview
Safety assertion mark Language (SAML, Security Assertion Markup Language) is developed by Oasis based on the XML Security Service Technical Committee (SSTC, OASIS XML-BASED Security Services Technical Committe). SAML is an XML-based framework for exchange safety information. Under this framework, the safety information is expressed as an assertion of the subject, and this subject is an entity (person or computer) that is uniquely identified in a particular domain in a certain area. A typical subject is an operator who uses Email uniquely positioned in an Internet DNS domain. As an assertion, it can be converted according to the main body, the attributes of the subject, authorization and other information (such as whether the main body is allowed to access a resource, etc.). As a result, it is expressed as an XML format and has a nesting structure. A single assertion can contain several different nodes for recording data for authentication, authorization, and attribute information. Note that the assertion contains the security verification result is a security verification that occurs. As a result of the verification results description of the name verification, attribute verification, authorization verification, policy judgment, etc. in SAML. SAML also defines a protocol that a client sends an assertion request and response (Request / Response) to SAML security verification. This protocol includes definitions of XML-based request / response message format. These messages can be bound to a lot of mainstream exchange transfer protocols, of course, SAML now only enables a binding -soap, which enables HTTP-based security verification requests and responses.
Why saml?
Why do you need SAML? Main 4 aspects:
l Side of the browser cookie: Most SSO (Single-Sign ON, single sign-on) products use the browser's cookie to keep the login status to avoid the overhead of the second login. But browser cookies cannot work across DNS nomenclas. So, if you get a cookie at WWW.ABC.com, you cannot be sent to "www.xyz.com" by any HTTP message. And this requirement cannot be satisfied when multi-enterprise organization across DNS nomenclas. Therefore, to solve the cross-domain SSO (CDSSO, Cross-Domain SSO) problem, other techniques are needed. So SSO products are solving CDSSO problems with non-cookie technology.
l SSO interoperability: Single sign-in product How to implement SSO or CDSSo is completely different from product. If the same organization is built across DNS named domain, or your application needs to organize and organize business partners collaboration, with CDSSO requirements, so you must use the same SSO product solution in all domains. At this time, SAML is a technique that the solution provider can often rely.
l Web Services Application requires: The security standards used in Web Services are still in defined. Most attention is concentrated on how to provide confidentiality, authorize completion solutions on a point-to-point. SAML standards provide such standards, identity authentication and authentication assertions, and other information can be exchanged between each other.
l The need for organizational joint: Simple positioning management of cross-organizational boundaries, which allows users to cut mergers for several different definition criteria as a single definition standard (or at least the number of standards).
