`
security
  • 浏览: 381067 次
  • 来自: www.pgp.org.cn
社区版块
存档分类
最新评论

转载SAML(From wikipedia，国内不能访问wp，所以转载到这里)

SOAPSSOExchangeSecurityAccess 
阅读更多

<!----> 1         <!----> SAML<o:p></o:p>

<!----> 2         <!----> From Wikipedia, the free encyclopedia<o:p></o:p>

Jump to: navigation, search<o:p></o:p>

Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between security domains, that is, between an identity provider and a service provider. SAML is a product of the OASIS Security Services Technical Committee.<o:p></o:p>

The single most important problem that SAML is trying to solve is the web single sign-on (SSO) problem. SSO solutions at the intranet level abound (using cookies, e.g.) but extending these solutions beyond the intranet has been problematic and has led to the proliferation of proprietary technologies that do not interoperate. SAML has become the definitive standard underlying many web SSO solutions in the identity management problem space.<o:p></o:p>

SAML assumes the principal (often a user) has enrolled with at least one identity provider. This identity provider is expected to provide local authentication services to the principal. However, SAML does not specify the implementation of these local services; indeed, SAML does not care how local authentication services are implemented (although individual service providers most certainly will).<o:p></o:p>

<!----> 3         <!----> Contents<o:p></o:p>

  • 1 SAML 1.0 <o:p> </o:p>
  • 2 SAML 1.1 <o:p> </o:p>
    • 2.1 SAML 1.1 Assertions <o:p> </o:p>
    • 2.2 SAML 1.1 Protocol <o:p> </o:p>
    • 2.3 SAML 1.1 Bindings <o:p> </o:p>
    • 2.4 SAML 1.1 Profiles <o:p> </o:p>
      • <st1:chsdate year="1899" month="12" day="30" islunardate="False" isrocdate="False" w:st="on"> 2.4.1 </st1:chsdate> SAML 1.1 Browser/Artifact Profile <o:p> </o:p>
      • <st1:chsdate year="1899" month="12" day="30" islunardate="False" isrocdate="False" w:st="on"> 2.4.2 </st1:chsdate> SAML 1.1 Browser/POST Profile <o:p> </o:p>
  • 3 References <o:p> </o:p>
  • 4 See also <o:p> </o:p>
  • 5 Implementations <o:p> </o:p>
  • 6 External links <o:p> </o:p>


<o:p> </o:p>

<!----> 4         <!----> SAML 1.0<o:p></o:p>

SAML 1.0 was adopted as an OASIS standard in Nov 2002. SAML has undergone one minor and one major revision since V1.0, which itself is a relatively simple protocol. SAML 1.0 is not just historical interest since the US Federal E-Authentication Initiative has adopted SAML 1.0 as its core technology.<o:p></o:p>

Fortunately, versions 1.0 and 1.1 of SAML are similar. See #SAMLDiff for specific differences between the two standards. This article concentrates on SAML 1.1 since it is the definitive standard on which most other standards and implementations depend.<o:p></o:p>

SAML 2.0 was approved in March 2005. SAM2.0 conformance SAML 1.1 and <st1:city w:st="on"><st1:place w:st="on">Liberty</st1:place></st1:city> alliance.<o:p></o:p>

<!----> 5         <!----> SAML 1.1<o:p></o:p>

SAML 1.1 was ratified as an OASIS standard in Sep 2003. The critical aspects of SAML 1.1 are covered in detail in the official documents #SAMLConform, #SAMLCore, and #SAMLBind. If you are new to SAML, you should probably read #SAMLOverview first.<o:p></o:p>

<!----> 6         <!----> SAML 1.1 Assertions<o:p></o:p>

SAML assertions are usually transferred from identity providers to service providers. Assertions contain statements that service providers use to make access control decisions. Three types of statements are provided by SAML:<o:p></o:p>

  1. Authentication statements <o:p> </o:p>
  2. Attribute statements <o:p> </o:p>
  3. Authorization decision statements <o:p> </o:p>

Authentication statements assert to the service provider that the principal did indeed authenticate with the identity provider at a particular time using a particular method of authentication. Other information about the principal may be disclosed in an authentication statement. For example, in the authentication statement below, the e-mail address of the principal is disclosed to the service provider:<o:p></o:p>

<saml:Assertion<o:p></o:p>

 xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"<o:p></o:p>

  MajorVersion="1" MinorVersion="1"<o:p></o:p>

 AssertionID="..."<o:p></o:p>

 Issuer="https://idp.org/saml/"<o:p></o:p>

 IssueInstant="<st1:chsdate year="2002" month="6" day="19" islunardate="False" isrocdate="False" w:st="on">2002-06-19</st1:chsdate>T17:05:37.795Z"><o:p></o:p>

 <saml:Conditions <o:p></o:p>

   NotBefore="<st1:chsdate year="2002" month="6" day="19" islunardate="False" isrocdate="False" w:st="on">2002-06-19</st1:chsdate>T17:00:37.795Z"<o:p></o:p>

   NotOnOrAfter="<st1:chsdate year="2002" month="6" day="19" islunardate="False" isrocdate="False" w:st="on">2002-06-19</st1:chsdate>T17:10:37.795Z"/><o:p></o:p>

 <saml:AuthenticationStatement<o:p></o:p>

   AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"<o:p></o:p>

   AuthenticationInstant="<st1:chsdate year="2002" month="6" day="19" islunardate="False" isrocdate="False" w:st="on">2002-06-19</st1:chsdate>T17:05:17.706Z"><o:p></o:p>

   <saml:Subject><o:p></o:p>

     <saml:NameIdentifier<o:p></o:p>

       Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"><o:p></o:p>

       user@mail.idp.org <o:p> </o:p>

     </saml:NameIdentifier><o:p></o:p>

     <saml:SubjectConfirmation><o:p></o:p>

       <saml:ConfirmationMethod><o:p></o:p>

         urn:oasis:names:tc:SAML:1.0:cm:artifact<o:p></o:p>

       </saml:ConfirmationMethod><o:p></o:p>

     </saml:SubjectConfirmation><o:p></o:p>

   </saml:Subject><o:p></o:p>

 </saml:AuthenticationStatement><o:p></o:p>

</saml:Assertion><o:p></o:p>

An e-mail address (as in the above example) will suffice in a large number of situations. In some cases, however, additional information is needed before a service provider can make an access control decision. As an example, suppose that students are allowed to access scholarships data. An attribute statement can indicate whether or not the principal has an affiliation of "student", which the service provider uses to allow or deny access (resp.) to the scholarships application:<o:p></o:p>

<saml:Assertion <o:p></o:p>

 xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"<o:p></o:p>

  MajorVersion="1" MinorVersion="1"<o:p></o:p>

 Issuer="https://idp.edu/saml/" ...><o:p></o:p>

  <saml:Conditions NotBefore="..." NotAfter="..."/><o:p></o:p>

 <saml:AuthenticationStatement<o:p></o:p>

   AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:X509-PKI"<o:p></o:p>

   AuthenticationInstant="..."><o:p></o:p>

   <saml:Subject>...</saml:Subject><o:p></o:p>

 </saml:AuthenticationStatement><o:p></o:p>

 <saml:AttributeStatement><o:p></o:p>

   <saml:Subject>...</saml:Subject><o:p></o:p>

   <saml:Attribute <o:p></o:p>

     AttributeName="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"<o:p></o:p>

     AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><o:p></o:p>

     <saml:AttributeValue Scope="idp.edu"><o:p></o:p>

       member<o:p></o:p>

     </saml:AttributeValue><o:p></o:p>

     <saml:AttributeValue Scope="idp.edu"><o:p></o:p>

       student<o:p></o:p>

     </saml:AttributeValue><o:p></o:p>

   </saml:Attribute><o:p></o:p>

 </saml:AttributeStatement><o:p></o:p>

</saml:Assertion><o:p></o:p>

Attributes are often obtained from an LDAP directory, so consistent representations of attributes across security domains is crucial.<o:p></o:p>

In the above example showing how a student might obtain access to a scholarships application, the service provider is functioning as both a policy enforcement point and a policy decision point. In some situations, it may be preferable to associate the policy decision point with the identity provider. In this case, the service provider passes a URI to the identity provider who asserts an authorization decision statement that dictates whether or not the principal should be allowed access to the secured resource at the given URI.<o:p></o:p>

<saml:Assertion <o:p></o:p>

 xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"<o:p></o:p>

  MajorVersion="1" MinorVersion="1"<o:p></o:p>

 Issuer="https://idp.org/saml/" ...><o:p></o:p>

  <saml:Conditions .../><o:p></o:p>

 <saml:AuthorizationDecisionStatement<o:p></o:p>

   Decision="Permit"<o:p></o:p>

   Resource="https://sp.org/confidential_report.html"><o:p></o:p>

   <saml:Action>read</saml:Action><o:p></o:p>

   <saml:Subject>...</saml:Subject><o:p></o:p>

 </saml:AuthorizationDecisionStatement><o:p></o:p>

</saml:Assertion><o:p></o:p>

The three statement types are not mutually exclusive. For example, both authentication statements and attribute statements may be included in a single assertion (as shown above). This precludes the need to make subsequent round trips between the service provider and identity provider.<o:p></o:p>

<!----> 7         <!----> SAML 1.1 Protocol<o:p></o:p>

The SAML protocol is a simple request-response protocol. A SAML requester sends a SAML Request element to a responder:<o:p></o:p>

<samlp:Request <o:p></o:p>

 xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" <o:p></o:p>

 MajorVersion="1" MinorVersion="1" <o:p></o:p>

 RequestID="..." <o:p></o:p>

 IssueInstant="..."><o:p></o:p>

 <!-- insert other SAML elements here --><o:p></o:p>

</samlp:Request><o:p></o:p>

Similarly, a SAML responder returns a SAML Response element to the requester:<o:p></o:p>

<samlp:Response<o:p></o:p>

 xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"<o:p></o:p>

 MajorVersion="1" MinorVersion="1"<o:p></o:p>

 ResponseID="..."<o:p></o:p>

 InResponseTo="..."<o:p></o:p>

 IssueInstant="..."><o:p></o:p>

 <!-- insert other SAML elements here, including assertions --><o:p></o:p>

</samlp:Response><o:p></o:p>

The bindings and profiles needed to affect this message exchange are detailed in the following sections.<o:p></o:p>

<!----> 8         <!----> SAML 1.1 Bindings<o:p></o:p>

SAML 1.1 defines just one binding, the SAML SOAP binding. A compatible SAML 1.1 implementation must implement SAML over SOAP over HTTP (asynchronous protocol). Other transport mechanisms are permitted provided the protocol-independent aspects of the SAML SOAP binding are observed (see section <st1:chsdate year="1899" month="12" day="30" islunardate="False" isrocdate="False" w:st="on">3.1.2</st1:chsdate> of #SAMLBind).<o:p></o:p>

The SAML 1.1 SOAP binding is built on top of version 1.1 of SOAP (the numbering is purely coincidental). A SAML requester wraps a SAML Request element within the body of a SOAP message. Similarly, a SAML responder returns a SAML Response element within the body of a returned SOAP message. If there is an error, the responder returns a SOAP fault code instead.<o:p></o:p>

Any SAML markup must be included in the SOAP body. SAML 1.1 does not define any SAML-specific SOAP headers. A requester is free to insert any SOAP headers it wishes (although none are required).<o:p></o:p>

Recall that in SOAP 1.1, a SOAPAction HTTP header must be included with each HTTP request (although its value may be empty). A SAML requester may give the following value to the SOAPAction header:<o:p></o:p>

SOAPAction: http://www.oasis-open.org/committees/security<o:p></o:p>

A SAML responder must not depend on this value, however.<o:p></o:p>

A secure connection is not required for SAML requests and responses, but in those situations where message integrity and confidentiality are required, HTTP over SSL 3.0 or TLS 1.0 with a server-side certificate is required.<o:p></o:p>

A SAML responder may return a "403 Forbidden" response when it refuses to respond to a SAML requester. A responder must return a "500 Internal Server Error" response in the event of a SOAP error (a SOAP fault element must be included as well). Otherwise, a "200 OK" response is returned, even in the presence of a SAML processing error. Such a response will include a SAML Status element in the SOAP body.<o:p></o:p>

<!----> 9         <!----> SAML 1.1 Profiles<o:p></o:p>

In general, profiles describe the HTTP exchanges required to ultimately transfer assertions from an identity provider to a service provider. SAML 1.1 specifies two browser-based, single sign-on profiles:<o:p></o:p>

  1. Browser/Artifact Profile<o:p></o:p>
  2. Browser/POST Profile<o:p></o:p>

These profiles support cross-domain single sign-on (SSO). The specification does not define any additional profiles. In particular, SAML 1.1 does not support a profile to secure a web service message nor does it support a single logout profile.<o:p></o:p>

Both SAML 1.1 profiles begin at the inter-site transfer service, which is managed by the identity provider. How the principal arrives at the transfer service in the first place is not dictated by the specification. See sections 4.1 and 4.2 of #SAMLOverview for possible scenarios. In practice, a client accessing a secured resource at a service provider will be redirected to the inter-site transfer service at the identity provider. Note, however, that the precise sequence of steps needed to accomplish this is not outlined by SAML 1.1. (See section 4.3 of #SAMLOverview for some rough ideas along these lines.) This issue is thoroughly addressed in SAML 2.0.<o:p></o:p>

After visiting the inter-site transfer service, the principal is transferred to the assertion consumer service at the service provider. Exactly how the principal is transferred from the inter-site transfer service to the assertion consumer service depends on the profile used. In the case of the Browser/Artifact Profile, a redirect is used; in the case of the Browser/POST Profile, the client issues a POST request (with or without user intervention).<o:p></o:p>

To expedite processing by the assertion consumer service, two separate URLs are specified:<o:p></o:p>

  1. Artifact Receiver URL (Browser/Artifact Profile)<o:p></o:p>
  2. Assertion Consumer URL (Browser/POST Profile)<o:p></o:p>

These and other URLs may be recorded in a SAML metadata archive.<o:p></o:p>

Note that a conforming SAML 1.1 identity provider must provide an inter-site transfer service. Similarly, a SAML 1.1 service provider must provide an assertion consumer service.<o:p></o:p>

SAML 1.1 Browser/Artifact Profile<o:p></o:p>

The Browser/Artifact Profile employs a "pull" mechanism. The profile essentially passes an SSO assertion from the identity provider to the service provider by reference, which is subsequently dereferenced via a back-channel exchange (i.e., the service provider "pulls" the assertion from the identity provider).<o:p></o:p>

The SAML 1.1 Browser/Artifact Profile specifies the following six (6) steps:<o:p></o:p>

1) Request the Inter-site Transfer Service<o:p></o:p>

The principal (user) requests the inter-site transfer service at the identity provider:<o:p></o:p>

https://idp.org/saml/TransferService?TARGET=target<o:p></o:p>

where target is the location of the desired resource at the service provider, say, https://www.sp.org/home. In other words, the following GET request is issued by the client:<o:p></o:p>

GET /saml/TransferService?TARGET=target HTTP/1.1<o:p></o:p>

Host: idp.org<o:p></o:p>

The profile does not specify how the URL to the transfer service (with target parameter) is obtained by the client.<o:p></o:p>

2) Redirect to the Assertion Consumer Service<o:p></o:p>

The principal is redirected to the assertion consumer service at the service provider; that is, the following response is returned to the client:<o:p></o:p>

HTTP/1.1 302 Found<o:p></o:p>

Location: https://sp.org/saml/ACS/Artifact?TARGET=target&SAMLart=artifact<o:p></o:p>

where artifact is a reference to an assertion the identity provider is willing to provide upon request. Important: It is assumed that the principal has already established a security context at the identity provider, otherwise the identity provider would not be able to subsequently assert the authenticity of the principal.<o:p></o:p>

3) Request the Assertion Consumer Service<o:p></o:p>

The client requests the assertion consumer service at the service provider:<o:p></o:p>

https://sp.org/saml/ACS/Artifact?TARGET=target&SAMLart=artifact<o:p></o:p>

where target and artifact are as before. In other words, the following GET request is issued by the client:<o:p></o:p>

GET /saml/ACS/Artifact?TARGET=target&SAMLart=artifact HTTP/1.1<o:p></o:p>

Host: sp.org<o:p></o:p>

4) Request the Artifact Resolution Service<o:p></o:p>

The assertion consumer service at the service provider begins a back-channel exchange with the artifact resolution service at the identity provider. The following SAML SOAP message is bound to an HTTP POST request:<o:p></o:p>

POST /saml/ArtifactResolutionService HTTP/1.1<o:p></o:p>

Host: idp.org<o:p></o:p>

Content-Type: text/xml<o:p></o:p>

Content-Length: nnn<o:p></o:p>

SOAPAction: http://www.oasis-open.org/committees/security
<!---->
<!----><o:p></o:p>

<?xml version="1.0"?><o:p></o:p>

<SOAP-ENV:Envelope<o:p></o:p>

  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><o:p></o:p>

  <SOAP-ENV:Header/><o:p></o:p>

  <SOAP-ENV:Body><o:p></o:p>

    <samlp:Request <o:p></o:p>

      xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" <o:p></o:p>

      MajorVersion="1" MinorVersion="1" <o:p></o:p>

      RequestID="_192.168.16.51.1024506224022" <o:p></o:p>

      IssueInstant="<st1:chsdate year="2002" month="6" day="19" islunardate="False" isrocdate="False" w:st="on">2002-06-19</st1:chsdate>T17:03:44.022Z"><o:p></o:p>

      <samlp:AssertionArtifact><o:p></o:p>

        artifact <o:p> </o:p>

      </samlp:AssertionArtifact><o:p></o:p>

    </samlp:Request><o:p></o:p>

  </SOAP-ENV:Body><o:p></o:p>

</SOAP-ENV:Envelope><o:p></o:p>

where artifact was previously sent from the identity provider to the service provider in steps 2 and 3.<o:p></o:p>

5) Respond with a SAML Assertion<o:p></o:p>

The artifact resolution service at the identity provider completes the back-channel exchange by responding with a SAML assertion:<o:p></o:p>

HTTP/1.1 200 OK<o:p></o:p>

Content-Type: text/xml<o:p></o:p>

Content-Length: nnnn
<!---->
<!----><o:p></o:p>

<?xml version="1.0"?><o:p></o:p>

<SOAP-ENV:Envelope<o:p></o:p>

  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><o:p></o:p>

  <SOAP-ENV:Header/><o:p></o:p>

  <SOAP-ENV:Body><o:p></o:p>

    <samlp:Response<o:p></o:p>

      xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"<o:p></o:p>

      MajorVersion="1" MinorVersion="1"<o:p></o:p>

      ResponseID="_P1YaA+Q/wSM/t/8E3R8rNhcpPTM="<o:p></o:p>

      InResponseTo="_192.168.16.51.1024506224022"<o:p></o:p>

      IssueInstant="<st1:chsdate year="2002" month="6" day="19" islunardate="False" isrocdate="False" w:st="on">2002-06-19</st1:chsdate>T17:05:37.795Z"><o:p></o:p>

      <samlp:Status><o:p></o:p>

        <samlp:StatusCode Value="samlp:Success"/><o:p></o:p>

      </samlp:Status><o:p></o:p>

      <!-- insert Assertion element here --> <o:p> </o:p>

    </samlp:Response><o:p></o:p>

  </SOAP-ENV:Body><o:p></o:p>

</SOAP-ENV:Envelope><o:p></o:p>

where the Assertion element was discussed earlier.<o:p></o:p>

6) Respond to the Principal's Original Request<o:p></o:p>

The assertion consumer service inspects the SAML Response element returned by the artifact resolution service, creates a security context at the service provider and redirects the client to the target resource.<o:p></o:p>

SAML 1.1 Browser/POST Profile<o:p></o:p>

分享到：
| CeltiXfireProposal让Axis2在Apache的地位 ...
评论
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

    SAML.rar_Java 8_saml_saml webservice_saml2.0_saml协议

    1、什么是SAML 2、SAML标准&协议 3、SAML2.0特性分析 4、SAML：集中身份管理的秘诀 5、SAML：企业级的IdP 6、SAML：IdP和SP用户存储库 7、XML安全：使用SAML确保可移植的信任 8、揭开SAML的神秘面纱 9、安全地共享...

    SAML2完整规范

    - `saml-bindings-2.0-os.pdf`：SAML2.0绑定，说明了如何将SAML信息绑定到各种传输机制。 - `saml-authn-context-2.0-os.pdf`：认证上下文，定义了不同类型的认证方式及其表示。 - `saml-metadata-2.0-os.pdf`：SAML...

    python-saml-master

    Python SAML库是用于在Python应用程序中实现Security Assertion Markup Language（SAML）身份验证的工具。SAML是一种标准，允许身份提供者（Identity Provider, IdP）和服务提供者（Service Provider, SP）之间交换...

    SAML v2.0 开发指南 SSO必备

    SAML提供了一种机制，允许用户通过使用现有的身份验证凭证从一个地方安全地访问多个应用程序。这种方式可以改善用户体验并降低企业的身份管理成本。本书《SAML v2.0 开发指南 SSO必备》是一个针对开发者的指南，它...

    SAML2.0 基础理论

    这有助于实现跨组织的SSO功能，使得用户只需要一次登录就能访问多个相互信任的服务。 **SAML2.0组件** 1. **SAML断言**：SAML断言定义了安全信息的数据格式，包括认证断言（表示用户已通过特定方式认证）、属性断言...

    saml2.0规范完全文档

    了解和掌握这些文档中的内容，对于实现和维护基于SAML 2.0的身份管理和访问控制系统至关重要。通过这些规范，开发者可以构建出安全、灵活且互操作的身份验证解决方案，以满足企业或组织的多样化需求。

    SAML v2 and XACML v2 Integration

    在IT领域，特别是针对身份管理和访问控制方面，SAML（Security Assertion Markup Language）与XACML（eXtensible Access Control Markup Language）是两个至关重要的标准。本文将深入探讨SAML v2与XACML v2在JBoss...

    saml-client_java_saml_client_

    1. **身份验证请求（AuthnRequest）**: 用户尝试访问服务提供者（SP）的受保护资源，SP向身份提供者（IdP）发送一个SAML认证请求。 2. **身份验证响应（AuthnResponse）**: IdP验证用户身份后，返回一个包含认证结果...

    SAML2.0协议翻译.doc

    2. **服务提供商发起的SSO**（SP-initiated SSO）：用户尝试访问SP服务时，如果未认证，SP会重定向用户到IdP进行身份验证，验证完成后返回SAML断言。 3. **响应/请求模式**（Response/Request Mode）：SP可以主动向...

    Laravel开发-laravel-saml

    在 Laravel 框架中，通过集成像 `laravel-saml` 这样的包，我们可以轻松地将SAML2支持添加到我们的应用中。 `laravel-saml` 是一个基于 OneLogin 工具包的 Laravel 扩展，它简化了在 Laravel 应用程序中实现 SAML2 ...

    Learning SAML

    《学习SAML：身份验证与单点登录的基石》 SAML（Security Assertion Markup Language，安全断言标记语言）是一种开放标准，用于在不同的信任域之间交换身份验证和授权数据。它在现代Web应用程序和企业级系统中扮演...

    saml第三方资料.rar

    总的来说，这个压缩包提供了丰富的SAML学习资源，涵盖了从基础概念到高级应用的各个方面，对于理解和开发基于SAML的身份验证系统非常有帮助。无论是初次接触SAML的开发者还是希望深化理解的技术人员，都能从中受益。

    SAML的标准与协议

    SAML的工作流程通常如下：当用户尝试访问一个服务（信任方）时，服务会重定向用户到身份提供者（断言方）进行身份验证。身份提供者验证用户后，生成一个包含用户身份信息的SAML断言，并将其返回给用户。用户携带这个...

    SAML2.0核心协议规范saml-core-2.0-os

    4. 安全特性：SAML规范包含安全方面的考虑，例如如何对断言进行数字签名和加密以确保其完整性、机密性和不可否认性。 5. 实体和角色：SAML定义了几个关键实体角色，包括： - 主体（Subject）：代表被声明的用户或...

    SAML文档详细介绍.pdf

    随着越来越多的企业和组织认识到联邦身份管理的重要性，SAML的应用场景和需求也将不断拓展。未来，SAML有望进一步优化其性能和安全性，以满足日益复杂和多样化的企业级身份管理需求。 综上所述，SAML作为一种成熟且...

    saml协议所需jar包

    5. **Java环境集成**: 在Java项目中，开发者需要将这些JAR包添加到项目的类路径中，以便在代码中引用和使用SAML相关类和方法。同时，可能还需要配置SAML处理相关的属性文件，如SP和IDP的元数据，以及签名和加密的...

    saml-profiles-2.0-os

    3. **安全实践和策略**：SAML 2.0 Profiles还详细阐述了与安全相关的实践和策略，包括但不限于数字签名、加密、身份验证方法的选择等。 #### 六、编辑者及贡献者 - **编辑者**：John Hughes (Atos Origin), Scott ...

    SAML协议交互，实现工程Demo（有注释）

    OpenSAML-ref-project-demo-v3 这一个使用...项目启动之后，访问如下网址： http://localhost:8080/webprofile-ref-project/app/appservlet 这是一个SP的模拟，第一次访问该网址时将会跳转到IDP，进行认证流程。

    redmine_saml-源码.rar

    - SSO是SAML的核心应用场景，允许用户通过一次登录就能访问多个相互信任的服务。 2. **Redmine SAML插件工作原理** - 插件在Redmine中添加了一个新的身份验证方法，允许用户通过SAML IdP进行身份验证。 - 用户...

Magicbox
Global site tag (gtag.js) - Google Analytics