安全断言标记语言(英语:Security Assertion Markup Language,简称SAML,发音sam-el)是一个基于XML的开源标准数据格式,它在当事方之间交换身份验证和授权数据,尤其是在身份提供者和服务提供者之间交换。SAML是OASIS安全服务技术委员会的一个产品,始于2001年。其最近的主要更新发布于2005年,但协议的增强仍在通过附加的可选标准稳步增加。
SAML解决的最重要的需求是网页浏览器单点登录(SSO)。单点登录在内部网层面比较常见,(例如使用Cookie),但将其扩展到内部网之外则一直存在问题,并使得不可互操作的专有技术激增。(另一种近日解决浏览器单点登录问题的方法是OpenID Connect协议)
SAML规范定义了三个角色:委托人(通常为一名用户)、身份提供者(IdP),服务提供者(SP)。在用SAML解决的使用案例中,委托人从服务提供者那里请求一项服务。服务提供者请求身份提供者并从那里并获得一个身份断言。服务提供者可以基于这一断言进行访问控制的判断——即决定委托人是否有权执行某些服务。
在将身份断言发送给服务提供者之前,身份提供者也可能向委托人要求一些信息——例如用户名和密码,以验证委托人的身份。SAML规范了三方之间的断言,尤其是断言身份消息是由身份提供者传递给服务提供者。在SAML中,一个身份提供者可能提供SAML断言给许多服务提供者。同样的,一个服务提供者可以依赖并信任许多独立的身份提供者的断言。
SAML没有规定身份提供者的身份验证方法;他们大多使用用户名和密码,但也有其他验证方式,包括采用多重要素验证。诸如轻型目录访问协议、RADIUS和Active Directory等目录服务允许用户使用一组用户名和密码登录,这是身份提供者使用身份验证令牌的一个典型来源。许多流行的互联网社交网络服务也提供身份验证服务,理论上他们也可以支持SAML交换。
SAML 断言示例代码:
<saml:Assertion xmlns:saml="urn:oasis:names����SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="b07b804c-7c29-ea16-7300-4f3d6f7928ac" Version="2.0" IssueInstant="2004-12-05T09:22:05Z"> <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature> <saml:Subject> <saml:NameID Format="urn:oasis:names����SAML:2.0:nameid-format:transient"> 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names����SAML:2.0����bearer"> <saml:SubjectConfirmationData InResponseTo="aaf23196-1773-2113-474a-fe114412ab72" Recipient="https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter="2004-12-05T09:27:05Z"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2004-12-05T09:17:05Z" NotOnOrAfter="2004-12-05T09:27:05Z"> <saml:AudienceRestriction> <saml:Audience>https://sp.example.com/SAML2</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2004-12-05T09:22:00Z" SessionIndex="b07b804c-7c29-ea16-7300-4f3d6f7928ac"> <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names����SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute xmlns:x500="urn:oasis:names����SAML:2.0:profiles:attribute:X500" x500:Encoding="LDAP" NameFormat="urn:oasis:names����SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1" FriendlyName="eduPersonAffiliation"> <saml:AttributeValue xsi:type="xs:string">member</saml:AttributeValue> <saml:AttributeValue xsi:type="xs:string">staff</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>
OASIS安全服务技术委员会(SSTC)于2001年1月首次举行会议,提出"定义一个用于交换身份验证和授权的XML框架。"为完成此目标,下列知识产权在该年的头两个月内向SSTC进行了捐献:
Security Services Markup Language(S2ML),来自Netegrity
AuthXML,来自Securant
XML Trust Assertion Service Specification(X-TASS),来自VeriSign
Information Technology Markup Language(ITML),来自Jamcracker
在这项工作的基础上,OASIS于2002年11月宣布"安全断言标记语言"(SAML)V1.0规范成为一个OASIS标准。
与此同时,大型企业、非营利及政府组织的联盟Liberty Alliance提出了一个扩展SAML标准的"自由联盟统一联合框架"(ID-FF)。与其前身SAML类似,Liberty ID-FF提出了一个标准化、跨域、基于Web的单点登录框架。此外,Liberty描绘了一个"信任圈"(circle of trust),其中每个参与域被信任将准确记录识别用户的过程、所使用的身份验证类型,以及任何与生成身份验证凭据相关的策略。信任圈中的其他成员可以查验这些策略,以决定是否信任此类信息。
虽然ID-FF开发了Liberty,SSTC已开始小规模升级到SAML规范。这使得SSTC在2003年9月批准了SAML V1.1规范。在同月,Liberty将ID-FF贡献至OASIS,从而为SAML下一版本奠基。2005年3月,SAML V2.0被宣布成为一项OASIS标准。SAML V2.0意味着Liberty ID-FF及其他专有扩展的收敛,以及包括SAML本身的早期版本。大多数SAML实现支持V2.0,并也大多支持V1.1以实现向后兼容。截至2008年1月,SAML V2.0的开发已在政府、高等教育和全球商业企业中普遍存在。
SAML自V1.0以来已进行一次重大及一次次要修订。
SAML 1.0于2002年11月获准成为OASIS标准
SAML 1.1于2003年9月获准为OASIS标准
SAML 2.0于2005年3月成为OASIS标准
Liberty Alliance在2003年9月将其自由联盟统一联合框架(ID-FF)贡献至OASIS SSTC:
ID-FF 1.1于2003年4月发布
ID-FF 1.2于2003年11月完成
SAML的1.0和1.1版本很类似,仅存在微小差异。
SAML 2.0与SAML 1.1则有着实质性的差异。虽然两者都是解决相同的使用案例,但SAML 2.0与1.1并不兼容。
尽管ID-FF 1.2已作为SAML 2.0的基础贡献至OASIS,但在SAML 2.0与ID-FF 1.2之间有着一些重要的差异。尤其是尽管这两个规范同根同源,但两者并不兼容。
SAML 创建在一些现有标准之上:
Extensible Markup Language (XML)
大多数SAML交换是以一个标准化的XML方言表示,这也是SAML的名称(Security Assertion Markup Language)的根源。; XML Schema (XSD): SAML断言和协议部分采用XML Schema。
XML Signature
SAML 1.1和SAML 2.0都为身份验证和消息完整性使用基于XML Signature标准的数字签名。
XML Encryption
SAML 2.0使用XML Encryption为加密名称标识符、加密属性和加密断言提供元素(SAML 1.1没有加密功能)。但XML加密据报有着严重的安全问题。
Hypertext Transfer Protocol (HTTP)
SAML很大程度上依赖超文本传输协议作为其通信协议。
SOAP
SAML指定使用SOAP,尤其是SOAP 1.1。
SAML定义了基于XML的断言、协议、绑定和配置。术语SAML核心(SAML Core)指SAML断言的一般语法和语义,以及用于请求和在系统实体间传输这些断言的协议。SAML协议指谁来传输,而不是如何传输(后者由所选择的绑定决定)。因此SAML核心只定义了"纯粹的"SAML断言,以及SAML的请求和响应元素。
SAML绑定决定SAML请求和响应如何映射到标准的消息或通信协议。一个重要的、同步的绑定是SAML SOAP绑定。
SAML配置是使用特定断言、协议和绑定组成的适用于所定义使用情况的一个具体表现形式。
本文向大家介绍sitecore 安全断言,包括了sitecore 安全断言的使用技巧和注意事项,需要的朋友参考一下 示例 CanRunApplication 检查用户是否有权运行给定的应用程序。如果没有,AccessDeniedException则抛出。 HasAccess HasAccess将检查给定参数是否为true,否则AccessDeniedException将抛出。
我有一个Java Web应用程序,我想将其作为服务提供商并实现SAML。我不确定如何做这件事的工作流程。 我已经阅读了这个SO问题,但仍然无法完全理解。在问题中,他们说他们需要向IDP发送请求,如果我是对的,称为断言。 如何创建断言?我在那里看到了样品。但是在哪里传递登录凭据呢? 另外,我如何在IDP注册我的应用程序,我是否需要安装IDP为此提供的一些证书?工作流程是什么? 谢谢
我正在使用多个SP实现单点登录。以下是我的基本理解: 1) 浏览器(用户)向服务提供商(SP)请求资源 2)SP重定向(使用SAML请求)到身份提供程序(IdP) 3)由于这是第一次登录,用户将向(IdP)提供其有效凭据 4)然后,IdP将浏览器(带有包含SAML令牌的SAML响应)重定向到SP页面。 现在,假设我有服务提供商A和服务提供商B。一个用户已经完成了关于服务提供商A的步骤。从服务提供商
我试图从开发人员的角度理解IdP发起的SSO的基本流程。我还试图从随。NET集成工具包。 基于此链接:http://documentation.pingidentity.com/display/PF610/OpenToken 适配器配置 问:PingFederate 服务器如何解析 SAML 断言?我是否必须从 SP 服务器对其进行编码?还是PingFederate服务器的设置会进行解析? 我现在
我们有一个产品有一个客户,当我们作为服务提供商并且idp在客户端时,我们使用Spring Security SAML为该客户实现了SAML流。 现在,我们有另一个客户也希望身份验证与 SAML 一起使用,并且我们希望同一 SP 为此客户实现 SAML 流,第二个客户还将有 2 个用于 SAML 的流,一个用于移动设备,另一个用于使用相同 IDP 的其他设备。两个客户的 IDP 是不同的。 问题 两
我正在JBOSS中实现SP启动的web浏览器SAML SSO配置文件。 我的应用程序是SP。 登录后,我希望IDP向我发送以下格式的加密断言: 对于一些国内流离失所者来说效果很好,但现在我有了一个国内流离失所者,它向我发送: 并且由于签名丢失,身份验证失败。 我的问题是:是否有SAML 2.0加密断言的标准格式,我可以告诉IDP管理员使用它?还是我必须支持这两种方式? 谢谢
我有一个webservice操作,其中我将获得SAML断言作为请求体的一部分。我跟踪XSD: saml:断言是指:< br>
我的任务是通过Sustainsys(Kentor)库为我目前正在进行的项目设置SAML 2.0单点登录。这是我一直遵循的文档。该网站是一个webforms应用程序,因此我使用Sustainsys库的HTTPModule部分。我已将IDP(Okta)配置为将SAML2.0断言发送到文档中声明endpoint为/SAML或/SAML/Acs的网站。该网站是Kentico CMS网站,CMS提供了一个A