前文OpenSAML 使用引导 II : Service Provider 的实现之AuthnRequest介绍从Service Provider（SP）角度出发，讲解如何使用OpenSAML如申请身份鉴别请求，并从IDP出得到断言的引用标识——SAML Artifact，本文将继续讨论Artifact的具体意义，如何使用Artifact换取断言信息，以及断言的使用方法。

相关阅读

SAML2.0入门指南,

OpenSAML 使用引导 I : 简介

源码地址：https://github.com/sunrongxin7666/OpenSAML-ref-project-demo-v3.git

更新 2017-11-20
回答网友xiajale的提问：为什么使用Artifact Binding，详情请见第六节

4. 第四步和第五步：The Artifact and Artifact Resolution

Artifact Resolve

Artifact Resolve Request

这里跳过了关于第三步身份认证的讨论，这是因为关于用户身份的认证完全取决于idp，和SAML协议本身没有关系。

当用户通过身份鉴别之后，Idp会为认证信息（断言）分配一个标识，这个标识被称为Artifact。Artifact将以URL参数的形式和用户一起被发送回SP。

SP为了通过Artifact得到真正的认证信息，需要构建ArtifactResolve对象，ArtifactResolve中包含Artifact。ArtifactResolve通过SOAP协议发送给Idp，Idp返回ArtifactResolveResponse，其中就包含了SAML Assertion，即认证信息。
由此可见Artifact对象至关重要，下面就来讨论Artifact的细节。

Artifact

Artifact是对一个SAML对象的引用。SAML规定Artifact中必须包括以下内容：

Artifact

TypeCode规定了当前Artifact的类型，不同类型的Artifact对于Remaining Artifact的格式有着不同的要求；
EndPointIndex代表着metadata中定义的Web服务终端标识，在用Artifact兑换真正的SAML对象时使用；
Artifact是这些部分Base64编码后的连续字节；
推荐的Artifact类型是type4

Artifact-type4

SourceID是发送者实体的ID被SHA-1哈希值；
MessageHandle是发送方对于SMAL消息真实的引用，为至少16位随机标识，不足20位的应该补全；

Artifact绑定（传输）

Artifact绑定是传输SAML信息（借助于其引用Artifact）的一种方式，通过HTTP客户端（如浏览器）来工作。传递Artifact有两种方式，HTTP POST和HTTP重定向。随后Artifact来换取真正的SAML消息，这一步靠SP和IDP可信信道来完成，比如SOAP信道。Artifact绑定的使用是因为SAML消息中有敏感信息，直接通过浏览器传送SAML消息并不安全。所以通过HTTP重定向传输Artifact，也就是说Artifact被当成URL中的参数传输。

创建ArtifactResolve

当SP得到Artifact之后，根据Artifact构造ArtifactResolve来请求真正的SAML消息。

Artifact artifact = OpenSAMLUtils.buildSAMLObject(Artifact.class); 
artifact.setArtifact(httpServletRequest.getParameter("SAMLart"));

然后构建ArtifactResolve对象

ArtifactResolve artifactResolve = OpenSAMLUtils.buildSAMLObject(ArtifactResolve.class);

接下来开始这是ArtfactResolve的各种属性：

Issuer：发送方的身份表示，同
AuthnRequest中的issuer;

Issuer issuer = OpenSAMLUtils.buildSAMLObject(Issuer.class);
issuer.setValue(SPConstants.SP_ENTITY_ID);
authnRequest.setIssuer(issuer);

Time of the Request

artifactResolve.setIssueInstant(new DateTime());

ID of the request:

artifactResolve.setID(OpenSAMLUtils.generateSecureRandomId());

destination URL

artifactResolve.setDestination(getIPDArtifactResloveDestination());

最后将Artifact加入其中：

artifactResolve.setArtifact(artifact);

形成的Artifact Request XML如下：

Artifact Request

使用SOAP协议发送 ArtifactResolve

SOAP简单的理解，就是这样的一个开放协议SOAP=RPC+HTTP+XML：采用HTTP作为底层通讯协议；RPC作为一致性的调用途径，ＸＭＬ作为数据传送的格式，允许服务提供者和服务客户经过防火墙在INTERNET进行通讯交互。
浅谈SOAP
SOAP 教程

RCP（Rmote Procedure Call）:远端程序调用，像调用本地对象那样调用远端的程序（方法），为同步过程，会拥塞调用代码的执行。

RPC vs REST : RPC，是面向服务的，关于行为和动作；REST面向资源的，强调描述应用程序的事务和名词。和REST相比，SOAP的优势在于能保证事物的原子性和消息可靠性，且对于数据完整性和数据隐私性的有很完备标准。

REST Vs SOAP，Soap 和 Rest 的区别

WebService的两种方式SOAP和REST比较

REST与SAOP的比较

和AuthnRequest类似，发送ArtifactResolve也是通过message context

MessageContext<ArtifactResolve> contextout 
    = new MessageContext<ArtifactResolve>();
contextout.setMessage(artifactResolve);

不过对于SOAP消息，没有强制的内容需要添加到环境上下文中，但是建议加入数据签名以增强安全性。

SignatureSigningParameters sigParameters = new SignatureSigningParameters();
sigParameters.setSignatureAlgorithm(SignatureConstants.ALGO_ID_SIGNATURE_RSA_SHA256);
sigParameters.setSigningCredential(SPCredentials.getCredential());
sigParameters.setSignatureCanonicalizationAlgorithm(SignatureConstants.ALGO_ID_C14N_EXCL_OMIT_COMMENTS);

SecurityParametersContext securityParametersContext = contextout.getSubcontext(SecurityParametersContext.class,true);
securityParametersContext.setSignatureSigningParameters(signatureSigningParameters);

因为涉及到两方的通信，还需要创建InOutOperationContext来处理输入输出的信息。

InOutOperationContext<ArtifactResponse, ArtifactResolve> context
    = new ProfileRequestContext<ArtifactResponse, ArtifactResolve>();
context.setOutboundMessageContext(contextout);

为了能发送SOAP消息，还需要设置SOAP Client。这个Client将会调用消息的处理器，编码器以及解码等来传送消息。这些内容将在下一章中详谈。

创建SOAP Client的具体做法为继承AbstractPipelineHttpSOAPClient并实现newPipline方法，来返回管道发送消息。

AbstractPipelineHttpSOAPClient<SAMLObject, SAMLObject> soapClient = new AbstractPipelineHttpSOAPClient() {
    protected HttpClientMessagePipeline newPipeline() throws SOAPException {
        //创建输入输出用的编码器和解码器
        HttpClientRequestSOAP11Encoder encoder
        = new HttpClientRequestSOAP11Encoder();
        HttpClientResponseSOAP11Decoder decoder
        = new HttpClientResponseSOAP11Decoder();
        //创建管道
        BasicHttpClientMessagePipeline pipeline
        = new BasicHttpClientMessagePipeline(
                encoder,
                decoder
        );
        //为输出的内容签名
        pipeline.setOutboundPayloadHandler(
        new SAMLOutboundProtocolMessageSigningHandler());
        return pipeline;
    }
}
// HTTP帮助SOAPClient编码和解码
HttpClientBuilder clientBuilder = new HttpClientBuilder(); soapClient.setHttpClient(clientBuilder.buildClient());
//发送soap消息
soapClient.send(IDPConstants.ARTIFACT_RESOLUTION_SERVICE, context);

SOAP消息发送之后，会同步等待Response返回或者超时。当Response返回时，SAML消息便可或得到：

return context.getInboundMessageContext().getMessage();

ArtifactResponse实例如下：

Artifact Resolve Response XML With Encrypted Assertion

加密断言部分

关于如何加密断言，将在下一个大章节中详细分析。

使用 Message Handlers 处理 SAML 消息

新版本OpenSAML的一大特点就是消息处理器容器（collection of message handlers）。这些消息处理来处消息并提供丰富的方法，如验证消息的有效性，验证签名，签名等等。处理器一般在解码器或者编码器之前调用。以下是一些可用的消息处理器：

MessageLifetimeSecurityHandler：生命周期验证，要求SAMLMessageInfoContext包含issue time;
SAMLOutboundProtocolMessageSigningHandler: 输出消息签名,要求SecurityParametersContext包含singing参数
ReceivedEndpointSecurityHandler：验证消息目的地址，要求base message context包含SAML消息，必需的信息可以从中提取出来；

消息处理器可以直接调用：

SAMLOutboundProtocolMessageSigningHandler handler = new SAMLOutboundProtocolMessageSigningHandler();
handler.initialize();
handler.invoke(context);

也可以在Client的实现中隐式调用，比如在PipelineHttpSOAPClient中那样。

当有多个处理器被调用时，可以使用BasicMessageHandlerChain来批量初始化和调用。

List handlers = new ArrayList<MessageHandler>(); 
handlers.add(handler1);
handlers.add(handler2);

BasicMessageHandlerChain<ArtifactResponse> handlerChain = new BasicMessageHandlerChain<ArtifactResponse>();
handlerChain.setHandlers(handlers);

以下是使用消息处理器的实例：
创建环境上下文：

MessageContext context = new MessageContext<ArtifactResponse>();
context.setMessage(artifactResponse);

将消息配置给SAMLMessageInfoContext，获得Issue内容：

SAMLMessageInfoContext messageInfoContext 
    = context.getSubcontext(SAMLMessageInfoContext.class, true);
messageInfoContext.setMessageIssueInstant(
    artifactResponse.getIssueInstant());

设置MessageLifetimeSecurityHandler

MessageLifetimeSecurityHandler lsHandler = new MessageLifetimeSecurityHandler();
lsHandler.setClockSkew(1000);
lsHandler.setMessageLifetime(2000);
lsHandler.setRequiredRule(true);

设置ReceivedEndpointSecurityHandler

ReceivedEndpointSecurityHandler receivedEndpointSecurityHandler = new ReceivedEndpointSecurityHandler();
receivedEndpointSecurityHandler.setHttpServletRequest(request);

将以上处理器放入处理器链中，批量处理：

List handlers = new ArrayList<MessageHandler>();
handlers.add(lifetimeSecurityHandler); 
handlers.add(receivedEndpointSecurityHandler); 

BasicMessageHandlerChain<ArtifactResponse> handlerChain = new BasicMessageHandlerChain<ArtifactResponse>(); 
handlerChain.setHandlers(handlers); 

handlerChain.initialize(); 
handlerChain.doInvoke(context);

5. 断言Assertion

SAML断言是认证的实体，其包含关于用户和身份鉴别的信息。以下来简单介绍下断言的内容。

断言用来承载安全信息，接收者可以根据这样的信息来做出安全访问控制决定。断言中所包含的安全信息被称为断言声明（assertion statement），共有三种类型：

认证声明：包含关于用户身份鉴别的信息，比如用户被认证身份的时间和方法；
属性声明：包含关于用户相关的属性信息，比如用户的姓名、手机号、邮箱和地址等等。这些属性被IDP定义为KEY—Value的形式
授权决定声明：确认当前用户是否授权来访问一个特殊的资源。身份鉴别决定只能提供最基本的鉴别能力，更为复杂情况推荐使用XACML(一种用于决定请求/响应的通用访问控制策略语言和执行授权策略的框架)。

5.1 断言的使用

断言在接收时是经过加密和签名的，这里对其的时候都是假设已经解密并通过签名验证的。

断言1

断言2

断言3

断言里包含很多的信息，下面将会展示从断言里提取需要的信息。

用户身份验证的时间在AuthnStatement字段的AuthnInstant 属性中

logger.info("Authentication instant: "
    +assertion.getAuthnStatements().get(0).getAuthnInstant());

用户被认证的方式在AuthnStatement子字段AuthnContext的AuthnContextClassRef属性值，标识认证的方式：

logger.info("Authentication method: "
    + assertion.getAuthnStatements().get(0).getAuthnContext()
    + .getAuthnContextClassRef().getAuthnContextClassRef());

AttributeStatement之中包含很多属性，都是Key_Value的形式：

for(Attribute attribute :
    assertion.getAttributeStatements()
        .get(0).getAttributes()) {
    logger.info("Attribute name: " + attribute.getName());
    for (XMLObject attributeValue : 
        attribute.getAttributeValues())
    {
        logger.info("Attribute value:"
            + ((XSString)attributeValue).getValue());
    }
}

6. 为什么使用Artifact Binding模式

SAML协议中如何使用Artifact Binding模式请求并获得断言流程已经为大家介绍完毕。不过有的读者可能有疑问，为什么要使用Artifact Binding模式，HTTP POST或者HTTP重定向直接获取断言信息不是更简单吗？的确是更简单，但是这样做有安全性的隐患。

其实SAML2.0中支持很多种绑定方式，如下都方式在OpenSAML中都有实现：

SAML SOAP Binding (based on SOAP 1.1)
Reverse SOAP (PAOS) Binding
HTTP Redirect (GET) Binding
HTTP POST Binding
HTTP Artifact Binding
SAML URI Binding

目前，基于浏览器的SSO中，HTTP POST和HTTP Redirect的模式用的最多，但是浏览器本身有很多的限制和缺陷，使得有时候不便直接通过浏览器获得身份认证断言：

URL中的查询字符串（Query String）或者POST payload有长度限制，无法装下断言信息（断言信息是XML格式，在签名加密之后往往很大）；
可能被注入JavaScript脚本，易遭受攻击，如跨站脚本攻击和跨站请求攻击；所以无法断定浏览器发出的请求是合法的，断言内的一些敏感信息不希望暴露给浏览器；
很多网站现在都是前后端分离开发，如果通过浏览器获得断言信息，前端代码还需要将断言信息通过API发送给后端，增加了断言信息在网络中的传输流程，也增加断言被窃取和篡改的风险（对于XML结构的数字签名有漏洞XML wrapping attacks）。

使用Artifact Binding就可以避免以上问题：

浏览器只是获得断言信息的引用（Artifact），而不是真正的断言，避免敏感信息暴露给浏览器，从而防止浏览器中潜在的风险和被攻击点；
Artifact换取断言的过程使用SOAP协议，不受HTTP请求中长度的限制；
SP向IDP换取断言的过程是服务器到服务器之间通信，可以使用HTTPS来确认双发的身份（浏览器中HTTPS往往只是单方向验证服务的身份，而没有验证浏览器的），非法的SP将无法获得真正的断言信息，并通信的过程加密传输，保证断言的安全；
Artifact是一次性，被使用过后就是无效的，无法重放攻击；
断言信息的请求和使用相分离，减少对于浏览器的依赖，更适用于前后端分离的SP；

其实如果熟悉OAuth中的授权码模式和默认模式的区别，SAML中使用Artifact或是HTTP Redirect也是异曲同工，依据使用场景不同而定。

更多关于SAML协议的是实现的内容，请参见本人编写的一系列教程文章，其介绍如何使用OpenSAML，欢迎阅读指正：

OpenSAML 使用引导 I : 简介

OpenSAML 使用引导 II : Service Provider 的实现之AuthnRequest

OpenSAML 使用引导 III: Service Provider 的实现之Artifact与断言

OpenSAMl 使用引导IV: 安全特性