eid security token frank cornelis - e-contract.be · eid security token service specifications 2...

1

eID Security Token

Service SpecificationsVersion 0.4.0

Frank Cornelis

Copyright © 2014-2019 e-Contract.be BVBA

Feb 15, 2019

Abstract

This document details on the eID Security Token Service specifications.

1. Introduction ................................................................................................................... 2

1.1. Namespaces ...................................................................................................... 2

1.2. References ......................................................................................................... 3

2. X.509 Certificate Token Profile ....................................................................................... 5

2.1. Request ............................................................................................................. 5

2.2. Processing ......................................................................................................... 7

2.3. Response ........................................................................................................... 7

2.4. Security Policy .................................................................................................... 9

3. SAML Token Profile ..................................................................................................... 10

4. Validating SAML assertions .......................................................................................... 13

5. STS based Validation .................................................................................................. 14

5.1. Request ............................................................................................................ 14

5.2. Processing ........................................................................................................ 15

5.3. Response ......................................................................................................... 15

6. Attributes ..................................................................................................................... 16

6.1. Request ............................................................................................................ 19

6.2. Processing ........................................................................................................ 20

6.3. Response ......................................................................................................... 21

6.4. Security Policy .................................................................................................. 21

7. Holder-of-key tokens .................................................................................................... 23

7.1. STS Request .................................................................................................... 23

7.2. STS Response ................................................................................................. 23

7.3. Usage .............................................................................................................. 24

7.4. Security Policy .................................................................................................. 25

8. Passive to Active Federation ........................................................................................ 27

8.1. Request ............................................................................................................ 27

eID Security Token

Service Specifications

2

8.2. Processing ........................................................................................................ 28

8.3. Response ......................................................................................................... 29

8.4. Extensions ........................................................................................................ 30

A. eID Security Token Service Specifications License ........................................................ 31

B. eID Security Token Service Project License .................................................................. 31

1. Introduction

eID authentication in a web context can be easily achieved using for example the eID Identity

Provider. Different protocols can be used for web based authentication: SAML 2.0 Browser POST

profile, WS-Federation web passive profile, OpenID 2.0, OAuth 2.0 or OpenID Connect. When

a relying party (a web application) authenticates an end-user, based on the eID, it can trust the

received claims.

In the context of native (desktop/fat-client) applications however, achieving a trust relationship

towards a remote relying party can be a challenge. In this document we define the specifications

for an Identity Provider Security Token Service (IP-STS) that accepts eID as primary credential.

This eID IP-STS is based on open standards like [WS-Trust] . The most important features of the

eID IP-STS are:

• The eID IP-STS is based on open standards.

• The eID IP-STS offers a secure challenge-response authentication based on the eID card.

• The eID IP-STS can be used with different out-of-the-box STS clients like Windows Identity

Foundations or Apache CXF STS Client.

• The eID IP-STS also supports 'lightweight' profiles for clients that have difficulties constructing

a [WS-Security] based signature.

• The usage of symmetric proof-of-possession keys can be made either mandatory or optional.

• The eID IP-STS provides a mechanism to allow remote relying parties to trust the authenticated

user.

1.1. Namespaces

The XML namespaces used in the following sections are described in Table 1, “XML Namespaces”

.

Table 1. XML Namespaces

Prefix Namespace

ds http://www.w3.org/2000/09/xmldsig#

soap http://www.w3.org/2003/05/soap-envelope

wsa http://www.w3.org/2005/08/addressing

eID Security Token


3

Prefix Namespace

wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-

wssecurity-secext-1.0.xsd

wsu http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-

wssecurity-utility-1.0.xsd

wst http://docs.oasis-open.org/ws-sx/ws-trust/200512

wsp http://schemas.xmlsoap.org/ws/2004/09/policy

ec http://www.w3.org/2001/10/xml-exc-c14n#

wsc http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512

saml2 urn:oasis:names:tc:SAML:2.0:assertion

xsi http://www.w3.org/2001/XMLSchema-instance

fed http://docs.oasis-open.org/wsfed/federation/200706

auth http://docs.oasis-open.org/wsfed/authorization/200706

sp http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702

wsaw http://www.w3.org/2006/05/addressing/wsdl

wsam http://www.w3.org/2007/05/addressing/metadata

wsx http://schemas.xmlsoap.org/ws/2004/09/mex

wsid http://schemas.xmlsoap.org/ws/2005/05/identity

wst14 http://docs.oasis-open.org/ws-sx/ws-trust/200802

1.2. References

[Base64] S. Josefsson, The Base16, Base32, and Base64 Data Encodings , The Internet Society,

2006 http://tools.ietf.org/html/rfc4648 [http://tools.ietf.org/html/rfc4648]

[Excl-C14N] J. Boyer et al., Exclusive XML Canonicalization Version 1.0 , World Wide Web Con-

sortium, July 2002 http://www.w3.org/TR/xml-exc-c14n/ [http://www.w3.org/TR/xml-exc-

c14n/]

[RFC 2616] R. Fielding et al., Hypertext Transfer Protocol - HTTP/1.1. , http://www.ietf.org/rfc/

rfc2616.txt IETF (Internet Engineering Task Force) RFC 2616, June 1999.

[SOAP] W3C, SOAP Version 1.2 , SOAP Version 1.2 [http://www.w3.org/TR/soap12-part1/] W3C

Recommendation 27 April 2007

[RFC 2246] T. Dierks, C. Allen, The TLS Protocol Version 1.0 , http://www.ietf.org/rfc/rfc2246.txt

IETF (Internet Engineering Task Force) RFC 2246, January 1999.

[WS-SecConv] A. Nadalin et al., WS-SecureConversation 1.4 , OASIS,

February 2009 http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/ws-

secureconversation.html [http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/

ws-secureconversation.html]

http://tools.ietf.org/html/rfc4648

http://tools.ietf.org/html/rfc4648

http://www.w3.org/TR/xml-exc-c14n/



http://www.ietf.org/rfc/rfc2616.txt


http://www.w3.org/TR/soap12-part1/

http://www.w3.org/TR/soap12-part1/


http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/ws-secureconversation.html




eID Security Token


4

[WS-Security] Kelvin Lawrence, Chris Kaler, OASIS Web Services Security: SOAP Message Se-

curity 1.1 , OASIS, February 2006 OASIS WS-Security 1.1 [https://www.oasis-open.org/

committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf]

[WS-SP] Kelvin Lawrence, Chris Kaler, OASIS WS-SecurityPolicy 1.2 , OASIS, July 2007 OASIS

WS-SecurityPolicy 1.2 [http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-

securitypolicy-1.2-spec-os.html]

[WSS-UT] Anthony Nadalin, Chris Kaler, Ronald Monzillo, Phillip Hallam-Baker OASIS

Web Services Security: UsernameToken Profile 1.1 , OASIS, February 2006

OASIS WS-Security UsernameToken Profile 1.1 [https://www.oasis-open.org/commit-

tees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf]

[WSS-SAML] Anthony Nadalin, Chris Kaler, Ronald Monzillo, Phillip Hallam-Baker OASIS Web

Services Security: SAML Token Profile 1.1 , OASIS, June 2005 OASIS WS-Se-

curity SAML Token Profile 1.1 [http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-pr-

SAMLTokenProfile-01.html]

[WSS-X509] Anthony Nadalin, Chris Kaler, Ronald Monzillo, Phillip Hallam-Baker OASIS Web

Services Security: X.509 Certificate Token Profile 1.1 , OASIS, February 2006 OASIS

WS-Security X.509 Certificate Token Profile 1.1 [http://docs.oasis-open.org/wss/v1.1/

wss-v1.1-spec-os-x509TokenProfile.pdf]

[WS-Trust] A. Nadalin et al., WS-Trust 1.3 , OASIS, March 2007 http://docs.oasis-

open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html [http://docs.oasis-open.org/ws-sx/

ws-trust/200512/ws-trust-1.3-os.html]

[WS-Trust14] A. Nadalin et al., WS-Trust 1.4 , OASIS, 25 April 2012 http://docs.oasis-

open.org/ws-sx/ws-trust/v1.4/ws-trust.html [http://docs.oasis-open.org/ws-sx/ws-trust/

v1.4/ws-trust.html]

[XHTML] XHTML 1.0 The Extensible HyperText Markup Language (Second Edition) , World Wide

Web Consortium Recommendation, August 2002 http://www.w3.org/TR/xhtml1/ [http://

www.w3.org/TR/xhtml1/]

[XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing , W3C Recommendation, June

2008 http://www.w3.org/TR/xmldsig-core/

[XML-ns] T. Bray, D. Hollander, A. Layman, Namespaces in XML , W3C Recommendation, Jan-

uary 1999 http://www.w3.org/TR/1999/REC-xml-names-19990114 [http://www.w3.org/

TR/1999/REC-xml-names-19990114]

[WSI-BSP] Michael McIntosh, Martin Gudgin, K. Scott Morrison, Abbie Barbir, Basic Security

Profile Version 1.1 , The Web Services-Interoperability Organization (WS-I), January

2010 http://www.ws-i.org/profiles/basicsecurityprofile-1.1.html [http://www.ws-i.org/pro-

files/basicsecurityprofile-1.1.html]

[WS-MEX] Doug Davis, Ashok Malhotra, Katy Warr, Wu Chou, Web Services Metadata

Exchange (WS-MetadataExchange) , W3C Recommendation 13 December 2011

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html




http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-pr-SAMLTokenProfile-01.html




http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-x509TokenProfile.pdf




http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html




http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html




http://www.w3.org/TR/xhtml1/



http://www.w3.org/TR/xmldsig-core/

http://www.w3.org/TR/1999/REC-xml-names-19990114



http://www.ws-i.org/profiles/basicsecurityprofile-1.1.html



eID Security Token


5

http://www.w3.org/TR/ws-metadata-exchange/ [http://www.w3.org/TR/ws-metadata-ex-

change/]

2. X.509 Certificate Token Profile

The first authentication construct is based on the OASIS WS-Security X.509 Certificate Profile

version 1.1 [WSS-X509] .

2.1. Request

The WS-Trust request SOAP message from the native client towards the eID IP-STS looks as

follows.

<soap:Envelope>

<soap:Header>

<wsa:Action soap:mustUnderstand="1">

http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue

</wsa:Action>

<wsa:MessageID>urn:uuid:...</wsa:MessageID>

<wsa:ReplyTo>

<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>

</wsa:ReplyTo>

<wsa:To s:mustUnderstand="1" u:Id="to">https://...</wsa:To>

<wsse:Security soap:mustUnderstand="1">

<wsu:Timestamp wsu:Id="timestamp">

<wsu:Created>2012-01-17T09:31:27.700Z</wsu:Created>

<wsu:Expires>2012-01-17T09:36:27.700Z</wsu:Expires>

</wsu:Timestamp>

<wsse:BinarySecurityToken wsu:Id="uuid-bst"

ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-

profile-1.0#X509v3"

EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-

security-1.0#Base64Binary">

...

</wsse:BinarySecurityToken>

<ds:Signature>

<ds:SignedInfo>

<ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

<ds:Reference URI="#timestamp">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>...</ds:DigestValue>

</ds:Reference>

<ds:Reference URI="#to">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

<ds:DigestValue>...</DigestValue>

</ds:Reference>

http://www.w3.org/TR/ws-metadata-exchange/



eID Security Token


6

</ds:SignedInfo>

<ds:SignatureValue>...</ds:SignatureValue>

<ds:KeyInfo>

<wsse:SecurityTokenReference>

<wsse:Reference URI="#uuid-bst"/>

</wsse:SecurityTokenReference>

</ds:KeyInfo>

</ds:Signature>

</wsse:Security>

</soap:Header>

<soap:Body>

<wst:RequestSecurityToken>

<wst:RequestType>

http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue

</wst:RequestType>

<wst:KeyType>

http://docs.oasis-open.org/ws-sx/ws-trust/200512/Bearer

</wst:KeyType>

<wst:TokenType>

http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0

<wst:TokenType>

<wsp:AppliesTo>

<wsa:EndpointReference>

<wsa:Address>urn:some-target-application</wsa:Address>

</wsa:EndpointReference>

</wsp:AppliesTo>

</wst:RequestSecurityToken>

</soap:Body>

</soap:Envelope>

The client sends this request towards the eID IP-STS over SSL ( [RFC 2246] ). This allows the

client to authenticate the eID IP-STS and gives us confidentiality and integrity.

The WS-Security XML signature SHOULD at least digest the <wsa:To> element and the

<wsu:Timestamp> element to achieve the required security properties for an entity authentication.

The signing of the <wsa:To> element prevents reuse of the XML signature within another con-

text (MITM attack). The value of the <wsa:To> element SHOULD correspond with the address

of the eID IP-STS instance used by the client application. The signing of the <wsu:Timestamp>

element serves as proof of message freshness towards the eID IP-STS as premisse for the entity

authentication.

Ideally <wsse:BinarySecurityToken> would be using #X509PKIPathv1 for

wsse:BinarySecurityToken/@ValueType as the eID IP-STS needs the complete X509 certifi-

cate chain to be able to perform a PKI validation. However, as Windows Communication Founda-

tion only supports #X509v3 the eID IP-STS must be able to contruct the certificate chain itself.

Note that an eID IP-STS implementation can also accept other non-eID X509 certificates.

To ensure interoperability with Windows Communication Foundation, the eID IP-STS should not

require compliance with WS-I Basic Security Profile Version 1.1 ( [WSI-BSP] ).

To ensure interoperability with Apache CXF, the eID IP-STS SHOULD also support the usage of

the <wst:SecondaryParameters> element.

eID Security Token


7

The <wst:KeyType> element indicates which type of proof of possession key should be returned

by the eID IP-STS. In this case, the client SHOULD require a bearer token that does not provide

any proof of possession.

The <wst:TokenType> element indicates the type of the token that should be returned by the eID

IP-STS. In this case a SAML 2.0 assertion bearer token will be returned.

The <wsp:AppliesTo> elements allows the eID IP-STS to determine which claims it can release

within the response SAML assertion.

2.2. Processing

The eID IP-STS performs the following processing:

• The XML signature SHOULD be verified using the <wsse:BinarySecurityToken> end-entity

certificate.

• The <wsse:BinarySecurityToken> X509 certificate chain should be validated using common

PKI validation rules (OCSP, CRL).

• The XML signature SHOULD at least sign the <wsa:To> element and the <wsu:Timestamp>

element.

• The <wsu:Timestamp> element SHOULD contain a valid time mark.

• The content of the <wsa:To> element SHOULD correspond with the eID IP-STS endpoint ad-

dress.

• The <wsp:AppliesTo> SHOULD indicate a known application.

2.3. Response

After a successful validation of the request message the eID IP-STS responds as follows.

<soap:Envelope>

<soap:Header>


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal

</wsa:Action>

<wsa:RelatesTo>urn:uuid:...</wsa:RelatesTo>





</wsu:Timestamp>

</wsse:Security>

</soap:Header>

<soap:Body>

<wst:RequestSecurityTokenResponseCollection>

<wst:RequestSecurityTokenResponse>

<wst:Lifetime>



eID Security Token


8

</trust:Lifetime>

<wsp:AppliesTo>


<wsa:Address>urn:some-target-application</a:Address>


</wsp:AppliesTo>

<wst:RequestedSecurityToken>

<saml2:Assertion ID="assertionId"

IssueInstant="2011-05-09T09:36:37.359Z" Version="2.0">

<saml2:Issuer>https://...</saml2:Issuer>

<saml2:Subject>

<saml2:NameID

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:transient">

71715100070

</saml2:NameID>

<saml2:SubjectConfirmation

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>

</saml2:Subject>

<saml2:Conditions NotBefore="2011-05-09T08:36:37.359Z"

NotOnOrAfter="2011-05-09T10:36:37.359Z">

<saml2:AudienceRestriction>

<saml2:Audience>

urn:some-target-application

</saml2:Audience>

</saml2:AudienceRestriction>

</saml2:Conditions>

<saml2:AuthnStatement AuthnInstant="2011-05-09T09:36:37.515Z">

<saml2:AuthnContext>

<saml2:AuthnContextClassRef>

urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI

</saml2:AuthnContextClassRef>

</saml2:AuthnContext>

</saml2:AuthnStatement>

<ds:Signature>

<ds:SignedInfo>



<ds:SignatureMethod


<ds:Reference URI="#assertion">

<ds:Transforms>

<ds:Transform

Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform


</ds:Transforms>

<ds:DigestMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>


</ds:Reference>

</ds:SignedInfo>


<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate>...</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</ds:Signature>

</saml2:Assertion>

eID Security Token


9

</wst:RequestedSecurityToken>

<wst:RequestedAttachedReference>

<wsse:SecurityTokenReference

wsse:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-

profile-1.1#SAMLV2.0">

<wsse:KeyIdentifier

ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">

assertionId

</wsse:KeyIdentifier>


</wst:RequestedAttachedReference>

<wst:TokenType>


</wst:TokenType>

<wst:RequestType>


</wst:RequestType>

<wst:KeyType>


</wst:KeyType>

</wst:RequestSecurityTokenResponse>

</wst:RequestSecurityTokenResponseCollection>

</soap:Body>

</soap:Envelope>

The value of the <wsa:RelatesTo> element corresponds with the value of the <wsa:MessageID>

element within the request message.

Both the <wsu:Timestamp> and the <wst:Lifetime> serve as proof of the message freshness

towards the client.

The <wst:RequestedSecurityToken> element contains the <saml2:Assertion> SAML 2.0

bearer token. The SAML 2.0 assertion has been signed using the eID IP-STS signing cer-

tificate. This XML signature MAY be verified by the requesting client before consuming the

<saml2:NameID> element within the SAML 2.0 assertion. The XML signature SHOULD be veri-

fied by alien relying parties when the SAML 2.0 assertion is used as a bearer token towards WS-

Security secured SOAP web services.

2.4. Security Policy

To easy integration with existing STS clients, eID IP-STS implementations should use the following

WS-SecurityPolicy [WS-SP] configuration.

<wsp:Policy wsu:Id="SecurityTokenServicePolicy">

<wsp:ExactlyOne>

<wsp:All>

<sp:TransportBinding>

<wsp:Policy>

<sp:TransportToken>

<wsp:Policy>

<sp:HttpsToken />

</wsp:Policy>

</sp:TransportToken>

eID Security Token


10

<sp:AlgorithmSuite>

<wsp:Policy>

<sp:Basic128 />

</wsp:Policy>

</sp:AlgorithmSuite>

<sp:IncludeTimestamp />

</wsp:Policy>

</sp:TransportBinding>

<sp:EndorsingSupportingTokens>

<wsp:Policy>

<sp:X509Token

sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/

AlwaysToRecipient">

<wsp:Policy>

<sp:WssX509V3Token11 />

</wsp:Policy>

</sp:X509Token>

<sp:SignedParts>

<sp:Header Name="To"

Namespace="http://www.w3.org/2005/08/addressing" />

</sp:SignedParts>

</wsp:Policy>

</sp:EndorsingSupportingTokens>

<wsaw:UsingAddressing />

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

To improve interoperability, eID IP-STS implementations should support WS-MetadataExchange

[WS-MEX] via the /mex suffix.

3. SAML Token Profile

A client can used the SAML 2.0 bearer token to secure the communication towards relying parties.

A SOAP request message can embed the SAML 2.0 bearer token according to OASIS WS-Secu-

rity SAML Token Profile 1.1.1 [WSS-SAML] . The following SOAP request message demonstrates

the usage of such a SAML 2.0 bearer token.

<soap:Envelope>

<soap:Header>





</wsu:Timestamp>

<saml2:Assertion ID="assertion"


...

</saml2:Assertion>

</wsse:Security>

</soap:Header>

<soap:Body>

...

</soap:Body>

eID Security Token


11

</soap:Envelope>

A relying party web service supporting WS-SecurityPolicy [WS-SP] could use the following security

policy.

<wsp:Policy wsu:Id="ExampleSamlSecurityPolicy">

<wsp:ExactlyOne>

<wsp:All>


<wsp:Policy>

<sp:TransportToken>

<wsp:Policy>

<sp:HttpsToken />

</wsp:Policy>


<sp:AlgorithmSuite>

<wsp:Policy>

<sp:Basic128 />

</wsp:Policy>



</wsp:Policy>


<sp:SignedSupportingTokens>

<wsp:Policy>

<sp:SamlToken>

<wsp:Policy>

<sp:WssSamlV20Token11 />

</wsp:Policy>

</sp:SamlToken>

</wsp:Policy>

</sp:SignedSupportingTokens>

<sp:Wss11>

<wsp:Policy>

<sp:MustSupportRefEmbeddedToken />

</wsp:Policy>

</sp:Wss11>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

A relying party web service could even refer directly to the eID IP-STS within the security policy

as shown below.


<wsp:ExactlyOne>

<wsp:All>


<wsp:Policy>

<sp:TransportToken>

<wsp:Policy>

<sp:HttpsToken />

</wsp:Policy>

eID Security Token


12


<sp:AlgorithmSuite>

<wsp:Policy>

<sp:Basic128 />

</wsp:Policy>



</wsp:Policy>



<wsp:Policy>

<sp:IssuedToken

sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/

IncludeToken/AlwaysToRecipient">

<sp:RequestSecurityTokenTemplate>

<wst:TokenType>


</wst:TokenType>

<wst:KeyType>


</wst:KeyType>

</sp:RequestSecurityTokenTemplate>

<wsp:Policy>

<sp:RequireInternalReference />

</wsp:Policy>

<sp:Issuer>

<wsa:Address>

http://www.w3.org/2005/08/addressing/anonymous

</wsa:Address>

<wsa:Metadata>

<wsx:Metadata>

<wsx:MetadataSection>

<wsx:MetadataReference>

<wsa:Address>

https://www.e-contract.be/iam/sts/mex

</wsa:Address>

</wsx:MetadataReference>

</wsx:MetadataSection>

</wsx:Metadata>

</wsa:Metadata>

</sp:Issuer>

</sp:IssuedToken>

</wsp:Policy>


<wsam:Addressing wsp:Optional="false">

<wsp:Policy />

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

The above security policy uses the WS-MetadataExchange feature of the eID IP-STS to allow for

easy configuration of STS clients.

eID Security Token


13

4. Validating SAML assertions

When a relying party receives a SAML 2.0 assertion as bearer token it SHOULD validate the SAML

assertion before proceeding. The relying party should at least verify the following conditions:

• Validate the XML signature on the SAML assertion. The XML signature should contain a

<ds:Reference> referring to the top-level <saml2:Assertion> element.

• The relying party SHOULD verify whether the value of the <saml2:Issuer> element corre-

sponds with the trusted eID IP-STS instance.

• The relying party SHOULD verify whether the SAML signatory corresponds with the trusted eID

IP-STS instance.

• The relying party SHOULD verify the freshness of the SAML 2.0 assertion via the NotBefore

and NotAfter attributes of the <saml2:Conditions> element.

• The relying party SHOULD verify that the SAML 2.0 assertion is indeed intended for him via

the <saml2:Audience> element.

A relying party can setup the trust relationship towards the eID IP-STS instance in different ways.

The relying party could for example keep reference of the SHA1 fingerprint of the trusted eID IP-

STS signing certificate. The relying party could also keep reference of the X509 certificate of the

trusted eID IP-STS instance.

To aid the relying party in the bootstrapping of the trust relationship towards the eID IP-STS, an

eID IP-STS instance should expose an OASIS SAML 2.0 metadata document. This SAML 2.0

metadata document SHOULD at least contain the following elements.

<md:EntityDescriptor entityID="https://...">

<md:RoleDescriptor xsi:type="fed:SecurityTokenServiceType"

protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706">

<md:KeyDescriptor use="signing">

<ds:KeyInfo>

<ds:X509Data>


</ds:X509Data>

</ds:KeyInfo>

</md:KeyDescriptor>

<fed:TokenTypesOffered>

<fed:TokenType Uri="urn:oasis:names:tc:SAML:2.0" />

</fed:TokenTypesOffered>

<fed:SecurityTokenServiceEndpoint>


<wsa:Address>https://...</wsa:Address>


</fed:SecurityTokenServiceEndpoint>

</md:RoleDescriptor>

</md:EntityDescriptor>

eID Security Token


14

A relying party SHOULD retrieve this SAML 2.0 metadata document over SSL. The eID IP-STS

signing certificate is located within the <md:KeyDescriptor> element.

5. STS based Validation

While a relying party can perfectly validate a received SAML assertion itself as described under

Section 4, “Validating SAML assertions” , it might be easier for some relying parties to use the

eID IP-STS itself to validate the SAML assertions.

5.1. Request

A relying party can send the following STS validation request to the eID IP-STS.

<soap:Envelope>

<soap:Header>


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Validate

</wsa:Action>


<wsa:ReplyTo>


</wsa:ReplyTo>






</wsu:Timestamp>

</wsse:Security>

</soap:Header>

<soap:Body>


<wst:RequestType>

http://docs.oasis-open.org/ws-sx/ws-trust/200512/Validate

</wst:RequestType>

<wst:TokenType>

http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Status

</wst:TokenType>

<wst:ValidateTarget>



...

</saml2:Assertion>

</wst:ValidateTarget>

<wsp:AppliesTo>




</wsp:AppliesTo>


</soap:Body>

</soap:Envelope>

The relying party should send the request over SSL towards the trusted eID IP-STS instance.

eID Security Token


15

Via the <wsp:AppliesTo> element the relying party can restrict the application context in which the

SAML assertion should be validated. Since according to the WS-Trust specification [WS-Trust] the

<wsp:AppliesTo> element is not mandatory, eID IP-STS implementations should also consider

this element as optional. This to prevent that vanilla STS clients cannot invoke the validation

operation on the STS.

5.2. Processing

The eID IP-STS SHOULD at least perform the following processing:

• The <wsu:Timestamp> element SHOULD contain a valid time mark.

• The content of the <wsa:To> element SHOULD correspond with the eID IP-STS endpoint ad-

dress.

• Validate the XML signature on the SAML assertion. The XML signature should contain a

<ds:Reference> referring to the top-level <saml2:Assertion> element.

• The eID IP-STS SHOULD verify whether the value of the <saml2:Issuer> element equals its

own name.

• The eID IP-STS SHOULD verify that he is the SAML signatory.

• The eID IP-STS SHOULD verify the freshness of the SAML 2.0 assertion via the NotBefore

and NotAfter attributes of the <saml2:Conditions> element.

• The eID IP-STS SHOULD verify that the SAML 2.0 assertion <saml2:Audience> element val-

ue corresponds with the <wsp:AppliesTo> element value from the request. This only if the

<wsp:AppliesTo> element has been provided.

5.3. Response

Upon successful processing, the eID IP-STS responds with:

<soap:Envelope>

<soap:Header>


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/ValidateFinal

</wsa:Action>



<wsu:Timestamp>



</wsu:Timestamp>

</wsse:Security>

</soap:Header>

<soap:Body>


<wst:TokenType>

http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/Status

</wst:TokenType>

eID Security Token


16

<wst:Status>

<wst:Code>

http://docs.oasis-open.org/ws-sx/ws-trust/200512/status/valid

</wst:Code>

<wst:Reason>

The Trust service successfully validated the input

</wst:Reason>

</wst:Status>


</soap:Body>

</soap:Envelope>

The relying party SHOULD at least check whether the <wst:Code> element value indeed indicates

a valid status.

6. Attributes

The active authentication as specified under Section 2, “X.509 Certificate Token Profile” results in

a SAML 2.0 assertion that only contains a subject <saml2:NameID> as unique user identifier. This

section describes various options to enrich the retrieved SAML assertion with attributes. Attributes

can have different origins:

• Attributes can be self claimed.

• Attributes can be derived from the eID card. As the eID card also offers different attributes

(name, address, ...), relying parties probably also want to access these eID attributes.

To allow the eID IP-STS to issue SAML assertions containing attributes, the relying party needs

to pass a specific SAML 2.0 assertion as part of the Section 2.1, “Request” . This specific SAML

assertion should be passed as SAML 2.0 bearer token within the <wst14:ActAs> WS-Trust 1.4

[WS-Trust14] element. We are using <wst14:ActAs> to achieve maximum interoperability when

using web service frameworks like Apache CXF or Windows Communication Foundation. The

specific SAML assertion looks as follows.

<saml2:Assertion ID="assertion-id"


<saml2:Issuer>self-claimed</saml2:Issuer>

<saml2:AttributeStatement>

<saml2:Attribute Name="urn:be:e-contract:sts:eid:identity">

<saml2:AttributeValue xsi:type="xs:base64Binary">

...

</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute Name="urn:be:e-contract:sts:eid:identity-signature">


...


</saml2:Attribute>

<saml2:Attribute Name="urn:be:e-contract:iam:claims:self-claimed:software-key">

<saml2:AttributeValue xsi:type="xs:string">

...

eID Security Token


17


</saml2:Attribute>

</saml2:AttributeStatement>

</saml2:Assertion>

Depending on the attributes that the eID IP-STS should return, other <saml2:Attribute> ele-

ments should be passed within the specific SAML 2.0 assertion. The eID IP-STS should support

the following specific input attributes:

urn:be:e-contract:sts:eid:identity

The eID identity file. The attribute value type should be xs:base64Binary .

urn:be:e-contract:sts:eid:identity-signature

The eID identity file signature by the national registration authority. The attribute value type

should be xs:base64Binary .

urn:be:e-contract:sts:eid:nr-cert

The X509 signing certificate used by the national registration authority. The attribute value

type should be xs:base64Binary .

urn:be:e-contract:sts:eid:address

The eID address file. The attribute value type should be xs:base64Binary .

urn:be:e-contract:sts:eid:address-signature

The eID address file signature by the national registration authority. The attribute value type

should be xs:base64Binary .

urn:be:e-contract:sts:eid:photo

The eID photo file. The attribute value type should be xs:base64Binary .

urn:be:e-contract:iam:claims:self-claimed:office-key

The self claimed office key. The attribute value type should be xs:string .

urn:be:e-contract:iam:claims:self-claimed:software-key

The self claimed software key. The attribute value type should be xs:string .

Eventually the eID IP-STS will deliver attributes as part of the SAML 2.0 bearer token. These

attributes are made available as <saml2:AttributeStatement> attributes within the SAML 2.0

bearer token. The eID IP-STS SHOULD support the following attributes:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

The URI for a claim that specifies the full name of an eID user. The attribute value type should

be xs:string .

eID Security Token


18

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

The URI for a claim that specifies the surname of an eID user. The attribute value type should

be xs:string .

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

The URI for a claim that specifies the given name of an eID user. The attribute value type

should be xs:string .

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/x500distinguishedname

The URI for a distinguished name claim of the eID X.509 authentication certificate. The at-

tribute value type should be xs:string .

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country

The URI for a claim that specifies the given name of an eID user. For eID users this defaults

to BE. The attribute value type should be xs:string .

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth

The URI for a claim that specifies the date of birth of an eID user. The attribute value type


http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender

The URI for a claim that specifies the gender an eID user. The attribute value type should

be xs:string .

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality

The URI for a claim that specifies the locality in which an eID user resides. The attribute value

type should be xs:string .

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode

The URI for a claim that specifies the postal code of an eID user. The attribute value type


http://schemas.xmlsoap.org/ws/2005/05/identity/claims/

privatepersonalidentifier

The URI for a claim that specifies the private personal identifier (PPI) of the eID user. The

attribute value type should be xs:string .

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress

The URI for a claim that specifies the street address (street and house number) of the eID

user. The attribute value type should be xs:string .

urn:be:e-contract:iam:claims:self-claimed:office-key

The self claimed office key. The attribute value type should be xs:string .

eID Security Token


19

urn:be:e-contract:iam:claims:self-claimed:software-key

The self claimed software key. The attribute value type should be xs:string .

Depending on the eID IP-STS policy, the eID IP-STS will enrich the SAML 2.0 bearer token with

attributes based on:

• The <wsp:AppliesTo> element.

• The optional <wst:Claims> element that should be part of the <wst:RequestSecurityToken>

element.

6.1. Request

A request that demonstrates the usage of eID attributes is given below. Here we omitted most

elements from the Section 2.1, “Request” message to better highlight the attribute sections.

<soap:Envelope>

<soap:Header>

...


...

</wsse:Security>

</soap:Header>

<soap:Body>


...

<wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity">

<wsid:ClaimType

Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"/>

<wsid:ClaimType

Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"/>

</wst:Claims>

<wsp:AppliesTo>




</wsp:AppliesTo>

<wst14:ActAs>

<saml2:Assertion ID="assertion-id"



<saml2:Attribute Name="urn:be:e-contract:sts:eid:identity">


...


</saml2:Attribute>

<saml2:Attribute Name="urn:be:e-contract:sts:eid:identity-signature">


...


</saml2:Attribute>

<saml2:Attribute Name="urn:be:e-contract:sts:eid:nr-cert">


...


eID Security Token


20

</saml2:Attribute>


</saml2:Assertion>

</wst14:ActAs>


</soap:Body>

</soap:Envelope>

As you can see from the example, the request for the surname and givenname claims, will re-

quire the provisioning of the eID identity file, the eID identity file signature, and the eID national

registration signing certificate. Otherwise the eID IP-STS cannot verify the security properties on

these eID data files, and thus cannot securely parse and assert the requested eID attributes. The

following table Table 2, “Attribute mapping” summarizes which input attributes should be provided

per requested claim type. Note that we omitted the prefixes for brevity.

Table 2. Attribute mapping

ClaimType Uri Attribute Name Uri

name identity , identity-signature , nr-cert

surname identity , identity-signature , nr-cert

givenname identity , identity-signature , nr-cert

x500distinguishedname Nothing.

dateofbirth identity , identity-signature , nr-cert

gender identity , identity-signature , nr-cert

locality identity , identity-signature , nr-cert , address , ad-

dress-signature

postalcode identity , identity-signature , nr-cert , address , ad-

dress-signature

streetaddress identity , identity-signature , nr-cert , address , ad-

dress-signature

software-key software-key

office-key office-key

6.2. Processing

When the eID IP-STS receives eID data files via the additional <saml2:Assertion> within the

request, is SHOULD perform the following additional processing, next to the processing already

defined under Section 2.2, “Processing” .

• Depending on the configured policy, determine whether the requested <wst:Claims> are per-

mitted by the calling application as indicated via <wsp:AppliesTo> .

• Check whether the provided eID data files are sufficient to meet the requested claims.

• Validate the eID identity file signature using the received national registration X509 certificate.

eID Security Token


21

• Perform a PKI validation against the national registration X509 certificate.

• Check the indicated validity period within the eID identity file.

• Check whether the national registration number within the eID identity file corresponds with the

SERIALNUMBER field of the eID authentication certificate distinguished name.

• Parse and (depending on the claims type) transform the eID identity attributes towards the

requested claims.

Similar processing applies to the eID address file if claims related to this file are requested.

6.3. Response

After successful processing, the eID IP-STS responds as follows. Again we omitted several re-

sponse elements to highlight the eID attribute relevant elements.

<soap:Envelope>

<soap:Header>

...

</soap:Header>

<soap:Body>



...




...


<saml2:Attribute

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">


Cornelis


</saml2:Attribute>

<saml2:Attribute

Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">


Frank


</saml2:Attribute>


</saml2:Assertion>




</soap:Body>

</soap:Envelope>


A relying party web service could use the following security policy.

eID Security Token


22


<wsp:ExactlyOne>

<wsp:All>


<wsp:Policy>

<sp:TransportToken>

<wsp:Policy>

<sp:HttpsToken />

</wsp:Policy>


<sp:AlgorithmSuite>

<wsp:Policy>

<sp:Basic128 />

</wsp:Policy>



</wsp:Policy>



<wsp:Policy>

<sp:IssuedToken




<wst:TokenType>


</wst:TokenType>

<wst:KeyType>


</wst:KeyType>

<wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity">

<wsid:ClaimType

Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" />

...

</wst:Claims>


<wsp:Policy>

<sp:RequireInternalReference />

</wsp:Policy>

<sp:Issuer>

<wsa:Address>


</wsa:Address>

<wsa:Metadata>

<wsx:Metadata>



<wsa:Address>


</wsa:Address>



</wsx:Metadata>

</wsa:Metadata>

</sp:Issuer>

</sp:IssuedToken>

</wsp:Policy>


eID Security Token


23


<wsp:Policy />

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

The above security policy explicitly states the requested claims towards the eID IP-STS via the

<wst:Claims> element.

7. Holder-of-key tokens

Under Section 2, “X.509 Certificate Token Profile” we described a way to retrieve bearer tokens.

Bearer tokens do not have proof keys while holder-of-key tokens do. A holder-of-key token is used

to ensure that messages sent from subject to RP are indeed from the subject claiming to have

sent them. This protocol-level protection guards against man in the middle attacks. Depending on

the relying party's web service policy some relying parties might require holder-of-key tokens.

7.1. STS Request

In this section we describe how the eID IP-STS can issue holder-of-key tokens where the proof-

of-possession key is an RSA key. For a relying party to request a holder-of-key token it should

extend the Section 2.1, “Request” message under <wst:RequestSecurityToken> as follows:

<wst:KeyType>

http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey

</wst:KeyType>

<wst:UseKey>

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>

...

</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

</ds:KeyInfo>

</wst:UseKey>

Here the <wst:UseKey> contains the RSA key to be used as proof-of-possession key in combi-

nation with the holder-of-key token issued by the eID IP-STS.

7.2. STS Response

When the eID IP-STS receives a request to issue a holder-of-key token, it will put the following

<saml2:SubjectConfirmation> within the returned <saml2:Assertion> .


eID Security Token


24

Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">

<saml2:SubjectConfirmationData xsi:type="saml2:KeyInfoConfirmationDataType">

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>

...

</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

</ds:KeyInfo>

</saml2:SubjectConfirmationData>

</saml2:SubjectConfirmation>

By using such holder-of-key token we basically switch from the X509 certificate trust model to a

SAML based trust model. Important to note here that the client keeps using the proof-of-posses-

sion key towards relying parties when presenting the corresponding SAML holder-of-key token.

The advantage of this mechanism is that the relying party no longer needs to perform a full PKI

validation of the eID authentication certificate chain. The relying party can simply trust the eID IP-

STS to already have executed the relevant PKI verifications as part of the token issuing.

7.3. Usage

The holder-of-key SAML token is used as described under Section 3, “ SAML Token Profile ” ex-

cept that we also include an XML signature as part of the WS-Security header. This XML signature

refers to the SAML token within its <ds:KeyInfo> as follows.

<soap:Envelope>

<soap:Header>

...

<wsa:To wsu:Id="To">https://www.e-contract.be/iam/example</To>

<wsse:Security soap:mustUnderstand="true">

<wsu:Timestamp wsu:Id="TS">



</wsu:Timestamp>

<saml2:Assertion ID="SAML-ID"

IssueInstant="2014-12-10T15:39:34.738Z"

Version="2.0">

...

</saml2:Assertion>

<ds:Signature>

<ds:SignedInfo>


Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">

<ec:InclusiveNamespaces PrefixList="soap"/>

</ds:CanonicalizationMethod>

<ds:SignatureMethod


<ds:Reference URI="#TS">

<ds:Transforms>

<ds:Transform


eID Security Token


25

<ec:InclusiveNamespaces PrefixList="wsse soap"/>

</ds:Transform>

</ds:Transforms>

<ds:DigestMethod



</ds:Reference>

<ds:Reference URI="#To">

<ds:Transforms>

<ds:Transform


<ec:InclusiveNamespaces PrefixList="soap"/>

</ds:Transform>

</ds:Transforms>

<ds:DigestMethod



</ds:Reference>

</ds:SignedInfo>


<ds:KeyInfo>


wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-


<wsse:KeyIdentifier


SAML-ID



</ds:KeyInfo>

</ds:Signature>

</wsse:Security>

</soap:Header>

<soap:Body>

...

</soap:Body>

</soap:Envelope>

To prevent certain attacks, the holder-of-key token should sign both the <wsu:Timestamp> ele-

ment and the <wsa:To> element.


A web service can use the following WS-SecurityPolicy to express the required usage of holder-of-

key tokens.

<wsp:Policy wsu:Id="HolderOfKeyPolicy">

<wsp:ExactlyOne>

<wsp:All>


<wsp:Policy>

<sp:TransportToken>

<wsp:Policy>

<sp:HttpsToken>

<wsp:Policy/>

eID Security Token


26

</sp:HttpsToken>

</wsp:Policy>


<sp:AlgorithmSuite>

<wsp:Policy>

<sp:Basic128/>

</wsp:Policy>


<sp:IncludeTimestamp/>

</wsp:Policy>


<sp:SignedEndorsingSupportingTokens>

<wsp:Policy>

<sp:IssuedToken




<wst:TokenType>


</wst:TokenType>

<wst:KeyType>


</wst:KeyType>


<wsp:Policy>

<sp:RequireInternalReference/>

</wsp:Policy>

<sp:Issuer>

<wsa:Address>


</wsa:Address>

<wsa:Metadata>

<wsx:Metadata>



<wsa:Address>


</wsa:Address>



</wsx:Metadata>

</wsa:Metadata>

</sp:Issuer>

</sp:IssuedToken>

<sp:SignedParts>

<sp:Header Name="To"

Namespace="http://www.w3.org/2005/08/addressing" />

</sp:SignedParts>

</wsp:Policy>

</sp:SignedEndorsingSupportingTokens>


<wsp:Policy/>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

eID Security Token


27

Note here the usage of <sp:SignedEndorsingSupportingToken> . Signed because of the used

SSL TransportBinding signs the supporting token . Endorsing because the holder-of-key token

adds a required proof-of-possession signature and thus endorses part of the message.

8. Passive to Active Federation

Within the context of web applications, it might be required to be able to invoke a web service on

behalf of the user that is currently logged in. Here the web application has already authenticated

the end-user by means of an identity provider and hence has a SAML assertion available. Such

SAML assertion is often called a passive SAML assertion, as it was acquired by means of a passive

(i.e., web browser based) authentication flow. However, given the limited validity of such passive

SAML assertions, direct usage of such passive SAML assertions for authentication towards a

SOAP web service might not be workable.

We define a WS-Trust version 1.4 [WS-Trust14] based STS that is capable of exchanging a short-

living passive SAML assertion for an active SAML assertion that can have a longer validity and

allows the web application to act on behalf of the authenticated end-user towards trusting web

services.

Special attention is given to the following aspects:

• Interoperability with different STS clients like the Apache CXF STS client and the Windows Com-

munication Foundation (WCF) framework using WSTrustChannelFactory and WSTrustChan-

nel.

• Security, to prevent any web application that acquired a passive SAML assertion to be able to

invoke the protected web services. The STS must be able to selectively allow only certain web

applications to exchange a passive SAML assertion for an active SAML assertion. Hence the

web application needs to perform a strong authentication towards the STS.

8.1. Request

The STS request looks as given below.

<soap:Envelope>

<soap:Header>


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue

</wsa:Action>



<wsa:ReplyTo>


</wsa:ReplyTo>


<wsse:BinarySecurityToken>

WS-Security X509 TOKEN HERE

eID Security Token


28

</wsse:BinarySecurityToken>




</wsu:Timestamp>

<ds:Signature>

WS-Security X509 SIGNATURE HERE

</ds:Signature>

</wsse:Security>

</soap:Header>

<soap:Body>


<wst:RequestType>


</wst:RequestType>

<wsp:AppliesTo>




</wsp:AppliesTo>

<wst:OnBehalfOf>

<saml2:Assertion>

PASSIVE SAML ASSERTION HERE

</saml2:Assertion>

</wst:OnBehalfOf>

<wst:TokenType>


</wst:TokenType>

<wst:KeyType>


</wst:KeyType>

<wst:Renewing/>


</soap:Body>

</soap:Envelope>

The STS client sends this request towards the STS over SSL ( [RFC 2246] ). This allows the client

to authenticate the STS and gives us confidentiality and integrity.

The STS client authenticates itself towards the STS by means of the WS-Security X509 profile

[WSS-X509]. This allows the STS to authenticate the (web) application.

The passive SAML assertion is passed towards the STS via the <wst:OnBehalfOf> element.

8.2. Processing

The STS performs at least the following processing:

• Authenticate the STS client using the WS-Security X509 profile signature.

• Validate the passive SAML assertion validity. Important here is that the STS trusts the certificate

of the identity provider that issued the passive SAML assertion and that the validity period still

applies.

eID Security Token


29

• Verify whether the requested <wsp:AppliesTo> URI is allowed for the authenticated STS client

and the verified passive identity provider.

• Optionally the STS could further ensure whether the passive identity provider indeed intented

to authenticate the end-user within the context of the calling STS client. This could be achieved

by also verifying the Recipient attribute of the <saml2:SubjectConfirmationData> element

within the passive SAML assertion as the Recipient attribute contains the URL of the landing

page within the web application where the passive identity provider delivered the SAML/WS-

Federation response. Notice here that the usage of <saml2:AudienceRestriction> here might

not be appropriate as this might not be specific enough, or could be influenced by rogue web

applications.

8.3. Response

In case of positive validation, the STS response looks as follows.

<soap:Envelope>

<soap:Header>


http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal

</wsa:Action>






</wsu:Timestamp>

</wsse:Security>

</soap:Header>

<soap:Body>



<wst:TokenType>


</wst:TokenType>

<wst:Lifetime>



</trust:Lifetime>

<wsp:AppliesTo>


<wsa:Address>urn:some-target-application</a:Address>


</wsp:AppliesTo>




<saml2:Issuer>https://...</saml2:Issuer>

<saml2:Subject>

<saml2:NameID

Format="urn:oasis:names:tc:SAML:1.1:nameid-format:transient">

71715100070

</saml2:NameID>


eID Security Token


30

Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>

</saml2:Subject>

<saml2:Conditions NotBefore="2011-05-09T08:36:37.359Z"

NotOnOrAfter="2011-05-09T10:36:37.359Z">

<saml2:AudienceRestriction>

<saml2:Audience>

urn:some-target-application

</saml2:Audience>

</saml2:AudienceRestriction>

</saml2:Conditions>

<ds:Signature>

<ds:SignedInfo>



<ds:SignatureMethod


<ds:Reference URI="#assertion">

<ds:Transforms>

<ds:Transform

Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform


</ds:Transforms>

<ds:DigestMethod



</ds:Reference>

</ds:SignedInfo>


<ds:KeyInfo>

<ds:X509Data>


</ds:X509Data>

</ds:KeyInfo>

</ds:Signature>

</saml2:Assertion>


<wst:RequestedAttachedReference>


wsse:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-


<wsse:KeyIdentifier


assertionId



</wst:RequestedAttachedReference>



</soap:Body>

</soap:Envelope>

8.4. Extensions

The STS might support the following extensions.

eID Security Token


31

8.4.1. Lifetime

The STS client might want to limit the validity of the acquiring SAML assertion to limit possible

abuse. The STS client can indicate the desired valid time range by means of the <wst:Lifetime>

element within the STS request. An example is shown below.

<wst:Lifetime>



</wst:Lifetime>

8.4.2. Holder-of-key

As the STS issued SAML assertions have a long lifetime, the web services might require a stricter

security model using holder-of-key SAML assertions. Hence the STS should also support the

issuing of holder-of-key SAML assertions. The STS client can indicate this within the STS request

as follows.

<wst:KeyType>


</wst:KeyType>

<wst:UseKey>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>...</ds:Modulus>

<ds:Exponent>...</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

</ds:KeyInfo>

</wst:UseKey>

Here the <wst:UseKey> contains the RSA public key to be used as proof-of-possession key in

combination with the holder-of-key token issued by the STS.

A. eID Security Token Service Specifications License

This document has been released under the Creative Commons 3.0 [http://creativecommons.org/

licenses/by-nc-nd/3.0/] license.

B. eID Security Token Service Project License

The eID Security Token Service Project source code has been released under the GNU LGPL

version 3.0.

http://creativecommons.org/licenses/by-nc-nd/3.0/



eID Security Token


32

This is free software; you can redistribute it and/or modify it under the terms

of the GNU Lesser General Public License version 3.0 as published by the Free

Software Foundation.

This software is distributed in the hope that it will be useful, but WITHOUT ANY

WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A

PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along

with this software; if not, see http://www.gnu.org/licenses/.

eid security token frank cornelis - e-contract.be · eid security token service specifications 2...

Documents