saml 2.0 interop test plan - liberty alliance · test plan for liberty alliance saml test event...

Test Plan for Liberty Alliance SAML Test Event

Test Criteria

SAML 2.0Version 3.1

Editor:

Kyle Meadors, Drummond Group Inc.

Abstract:

This document describes the test steps to achieve the Liberty Interoperable™ designation for various SAML 2.0 modes and profiles.

Filename:

Liberty_Interoperability_SAML_Test_Plan_v3.1.odt

1

2

3

4

5

6

7

89

10

11

Liberty Alliance Project Version 3.1SAML 2.0 Test Steps

ContentsIntroduction.....................................................................................................................................3

Overview of Test Plan.......................................................................................................................3Test Plan History...............................................................................................................................3SAML Conformance Modes..............................................................................................................3eGov Profile.......................................................................................................................................4POST Binding....................................................................................................................................4

Technical Requirements................................................................................................................5Metadata............................................................................................................................................5IdP Authentication.............................................................................................................................5Trivial Processing..............................................................................................................................5Authentication Contexts.....................................................................................................................5Name Identifier Formats....................................................................................................................6XML Signatures.................................................................................................................................6XML Encryption................................................................................................................................7Attribute Profiles...............................................................................................................................7Consensus Items................................................................................................................................7

Test Cases........................................................................................................................................9Overview of Test Case Description...................................................................................................9Test Cases Associated with Conformance Modes..............................................................................9General Test Case Requirements.....................................................................................................10Test Case A – Redirect Binding.......................................................................................................10Test Case B – SOAP Binding..........................................................................................................13Test Case C – POST Binding...........................................................................................................16Test Case D – Extended SAMLModes............................................................................................19Test Case E – IDP Introduction.......................................................................................................22Test Case F – Single Session Logout...............................................................................................23Test Case G – Unsolicited <Response>...........................................................................................25Test Case H – Affiliations................................................................................................................26Test Case I – Multiple SP Logout....................................................................................................28Test Case J – Force Authentication and Passive Authentication......................................................30Test Case K – ECP...........................................................................................................................32Test Case L – SAML Authentication Authority...............................................................................33Test Case M – SAML Attribute Authority.......................................................................................35Test Case N – SAML Authorization Decision Authority.................................................................37Test Case O – SAML URI Binding.................................................................................................39Test Case P – Error Testing.............................................................................................................40Test Case Q – eGov Profile..............................................................................................................42

References......................................................................................................................................46

Liberty Alliance Project

2

121314151617181920212223242526272829303132333435363738394041424344454647484950


Introduction

Overview of Test PlanThis document is the Liberty SAML 2.0 Test Criteria Test Plan, which contains the scope of the technical requirements for Liberty certification of SAML 2.0. This document is intended to be publicly viewable through the Liberty Alliance website as well as prospective test participants.

The contents of this document include the test cases for Liberty SAML 2.0 certification as well as additional technical information relevant to testing. The test cases include different test steps, which as a whole cover the requirements of the SAML profiles [SAMLProf] and SAML conformance modes [SAMLConf].

Another document, Liberty SAML 2.0 Process Test Plan, contains the detailed testing process and test administration requirements for the SAML 2.0 certification test. The Liberty SAML 2.0 Process Test Plan is available only to registered test participants. While the Process Test Plan is used in completing a certification event, it is not needed to understand the technical expectation for completing SAML 2.0 certification.

Test Plan History

This test plan replaces SAML 2.0 Interoperability Testing Procedure (vs. 3.0) test plan [SAMLTP30]. The changes to this version are modifications to Test Case E and Q and new additions of Test Cases I and J. Also, consensus items reached from the last interoperability test event have been included here.

• SAML 2.0 Interoperability Testing Procedure, vs. 3.0.J (11/20/2007)

• SAML 2.0 Interoperability Testing Procedure, vs. 2.0 (07/07/2006)

• SAML 2.0 Interoperability Testing Procedure, vs. 1.0 (2005)

SAML Conformance Modes

This test plan document contains test cases that cover the nine operational conformance modes of SAML 2.0 and the specific features that are required or optional for each mode. The details of each mode are provided in [SAMLConf], and the conformance modes a listed here:

• IdP – Identity Provider

• IdP Lite – Identity Provider Lite

• SP – Service Provider

• SP Lite – Service Provider Lite

• ECP – Enhanced Client/Proxy

• IdP Extended – Identify Provider Extended

• SP Extended – Service Provider Extended

• SAML Attribute Authority

• SAML Authorization Decision Authority


3

51

52

535455

56575859

6061626364

65

666768

69

70

71

72

737475

76

77

78

79

80

81

82

83

84


• SAML Authentication Authority

• SAML Requester

Each conformance mode requires different test cases, but some test cases cover multiple conformance modes. The required test cases for each conformance mode are noted in the Test Case section of this document.

Certification in conformance modes IdP Extended and SP Extended can only be given if a participant has met the certification requirements of one of the standard SP or IdP modes.

Because significant features in some of these modes are Optional the Liberty Interoperability Testing Program has created an additional designation “SP Complete” to recognize and differentiate implementations that demonstrate interoperability of all optional features for the SP conformance mode.

eGov ProfileThe eGov Profile test case is an optional test case. It follows the SAML 2.0 requirements for the General Service Administration (GSA) of the US Government. The technical requirements for this test case come from the GSA SAML Profile in [GSAInterface], [GSAAdoptSchm] and [GSATechAppr]. These documents should be consulted for further explanation of the eGov requirements.

POST BindingAlthough the POST binding is not included in the SAML SCR, it is permitted with the SAML specification and has some user deployment. POST Binding is an optional Liberty designation conformance mode. It involves use of POST binding for AuthnRequest, Name ID Management and SLO. Certification in the POST Binding mode is done through successfully completing this test case.


4

85

86

878889

9091

92939495

96

979899

100

101

102103104105


Technical Requirements

MetadataThere are no normative requirements in [SAMLConf] regarding the content or processing of metadata as described in [SAMLMeta]. However, for purposes of this certification event, implementations are required to:

• Furnish correct metadata, and

• Process metadata furnished by other testing partners

While metadata is not specified for SAML Attribute Requesters, interoperability with SAML Authorities is very difficult without it, and for this certification event it is required that SAML Attribute Requesters provide metadata as described in the draft metadata extension specification [SAMLMetaExt]. It is not necessary or meaningful for an ECP to produce or consume metadata.

IdP AuthenticationSAML does not normatively specify any requirements for user authentication at IdP for Web SSO. In fact, user authentication is explicitly described as “out of scope” [SAMLProf]. However, for purposes of interoperability testing, it is required that IdP implementations offer at least one of these authentication methods:

1. HTTP Basic Auth.2. HTTP Form Post3. HTTP Get

Similarly, it is required that user agents, particularly ECP implementations, be able to authenticate using at least one of these methods.

Trivial ProcessingSeveral features specified by SAML (e.g., IdP Proxy) can be implemented such that any request simply returns an error response. While this trivial behavior is, strictly speaking, in conformance with the specifications, it is not meaningful in the context of interoperability testing. Except where explicitly indicated (e.g., for certain Name Identifier formats) all testing steps will require non-trivial responses in order to be deemed successful.

Authentication ContextsSome of the SAML Modes rely on a well-defined ordering of authentication contexts. The SAML specifications do not normatively specify an ordering [SAMLAuthnCxt] and leave the comparison decisions up to the implementation [SAMLCore]. However, for purposes of testing we will arbitrarily define an ordering of authentication contexts to be used in the tests. This arbitrary listing of authentication class URIs, in order of increasing strength, is:

1. any defined authentication context not listed below

2. urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession

3. urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol


5

106

107

108109110

111

112

113114115116

117

118119120121

122123124125126

127

128129130131132

133

134135136137138

139

140

141


4. urn:oasis:names:tc:SAML:2.0:ac:classes:Password

This ordering should be observed by all implementations testing SAML modes where authentication contexts must be compared. The overall concept of the testing of the Authentication Authority is to create several different assertions using different authentication contexts. Then these are queried using the query terms (“exact”, “better”, “maximum”, “minimum”) and a reference authentication context.

NOTE: Complete implementation of these authentication contexts is not required. These authentication context URIs should simply be asserted in requests and responses to demonstrate interoperability of authentication context processing rules.

Name Identifier FormatsThe following Name Identifier Formats are defined by [SAMLCore]:

1. Unspecified

2. Email

3. X.509 Subject

4. Windows

5. Kerberos

6. Entity

7. Persistent

8. Transient

Every implementation is required to accept messages containing any of these formats, but [SAMLCore] only requires that the last two be processed.

XML SignaturesThe [SAMLConf] does not specifically indicate where XML Signatures are required, but the underlying specifications in [SAMLProf] make signing required for certain profiles. Specifically, these are:

1. Web SSO: The assertion element(s) in the <Response> MUST be signed for the HTTP POST binding.

2. ECP Profile: The assertion element(s) in the <Response> issued by the IdP MUST be signed.

3. Single Logout: The <LogoutRequest> and <LogoutResponse> MUST be signed for the HTTP redirect binding.

4. Name Identifer Management: The <ManageNameIDRequest> and <ManageNameIDResponse> MUST be signed for the HTTP redirect binding.

SP and IdP implementations may indicate via metadata a desire for requests or responses to be signed for other bindings than those indicated above. However, such stipulations in metadata are not binding and adherence is not required.


6

142

143144145146

147148149

150

151

152

153

154

155

156

157

158

159

160161

162

163164165

166167

168

169170

171172

173174175


XML Encryption[SAMLConf] stipulates several different encryption algorithms and key transport mechanisms that MUST be implemented. However, these testing procedures do not require demonstration of support for all these combinations and instead rely on successful interoperability as a measure of conformance. Implementations should take care to ensure that elements to be encrypted include any XML namespace prefix declarations so that, when decrypted, the element will remain valid independent of context. One method for achieving this is described in [ExcXMLCan], but other approaches will work.

Note that while the <ds:KeyInfo> and <xenc:EncryptedKey> elements are not required in the SAML specifications or related schemas, these elements MUST be included in messages for interoperability testing. There is no normative mechanism for exchanging these keys out-of-band. The precise location of these elements in the message is underspecified; the most common practice among interoperable SAML implementations is that in each encrypted element there be one <xenc:EncryptedKey> element in parallel with the <xenc:EncryptedData>, and that this <xenc:EncryptedKey> be inferred as the relevant key information for decryption without relying on any references within the subelements. An erratum has been created to clarify this; see PE43 in [SAMLErrata]. For this certification event, this most common practice stated above SHOULD be done.

Finally, encryption coupled with deflation and URL encoding may create URLs that exceed the maximum length supported by some browsers. Consequently, encryption is contraindicated for the MNI HTTP-Redirect testing steps.

Attribute Profiles[SAMLConf] makes no normative statements about which Attribute Profiles in [SAMLProf] are required to be supported by SAML Attribute Authority or a SAML Requestor. These are the profiles described in [SAMLProf] except for X.500/LDAP, which is described in [SAMLLDAP]:

1. Basic

2. X.500/LDAP

3. UUID

4. DCE PAC

5. XACML

Of these, this document only describes testing procedures for the Basic profile, and does not describe any testing procedures regarding the other profiles.

Consensus ItemsConsensus Items contains standards/implementation issues the product test group reached consensus on in previous Liberty test events in order to achieve interoperability among those product test groups. In order to maintain interoperability with previously tested versions, the consensus items will be observed in this test event.

• DSAwithSHA1 signature algorithm not supported. Section 4.1 of [SAMLConf] states that the DSAwithSHA1 signature algorithm, while recommended, is not required by SAML 2.0. Participants are only to use digital certificates with the required RSAwithSHA1 signature algorithm.


7

176

177178179180181182

183184185186187188189190191

192193194

195

196197198

199

200

201

202

203

204205

206

207208209210

211

212213214


• Ignore EncryptionMethod elements in metadata. There is some confusion of interpretation implementation of the EncryptionMethod metadata elements described in Section 2.4.1.1 of [SAMLMeta]. After confirming with OASIS SSTC, EncryptionMethod is to be ignored.

• Encryption with NameIDPolicy and ID Encryption. A question had arisen on interpreting NameIDPolicy from [SAMLCore] in lines 2136-2142. It was decided that if NameIDPolicy of AuthnRequest says ID is to be encrypted, it must be encrypted in the assertion and if NameIDPolicy of AuthnRequest does not state the ID is to be encrypted, the IDP MAY still encrypt the ID based on its policy, specifically its policy with the SP.

• SSL Server-side Authentication Only for SOAP connections. To insure all participants used the same security settings, it was agreed to only use SSL server-side authentication for SOAP connections and not to use SSL client-side authentication.


8

215

216217

218

219220221222

223

224225


Test Cases

Overview of Test Case DescriptionEach test case is setup with the first part listing an overview of the test steps in the test case. The second part describes the details of the individual test steps to carry out the test case. The test step overview lists the sequence of test steps along with a general description of the message or action or configuration setting required. The test step details provide more information on the expected test steps.

Test Cases Associated with Conformance ModesIn order to achieve certification in one or more of the Liberty SAML Conformance Modes, the associated test cases must be completed with all test participants with aligning modes. For example, a product testing for an IdP conformance mode must complete Test Cases A, B, C, E, F, G, H and I against all products testing for a SP and SP Lite conformance mode. The specific pairing among participants will be given at the beginning of the certification event. A conformance mode may not require completion of all the test steps in the associated test cases. The individual test cases provide details of test steps that may or must be omitted depending on the conformance mode.

Conformance Mode Test CasesIdP A, B, E, F, G, H, I, J, K, PIdP Extended DIdP Lite A, B, E, F, G, H, I, J, KSP A, B, C, E, F, G, H, I, J, K, PSP Extended DSP Lite A, B, C, E, F, G, H, I, J, K, PECP KSAML Attribute Authority MSAML Authorization Decision Authority NSAML Authentication Authority LSAML Requester O


9

226

226

226227228229230

226

226227228229230231232


General Test Case RequirementsFor all test cases, the following requirements are to be followed unless a test case specifically states otherwise:

• SAML AuthnRequest MUST be signed.

• For POST bindings, the assertion MUST be signed.

• For POST bindings, the entire response message MAY be signed, but if signed, the receiving partner MUST validate the signature.

• Encryption of NameIDs and Assertions MUST be enabled.

Test Case A – Redirect BindingPreconditions: Metadata exchanged and loadedConformance Modes: IdP, SP, IdP Lite, SP Lite

NOTE – IdP Lite and SP Lite actors are to ignore Name ID Management steps

Test Step OverviewSteps Action/Message/Setting

1 Encryption Enabled

2 Web SSO HTTP redirect / Persistent / Federate

3 MNI IdP-Initiated / HTTP redirect (signed)

4 SLO SP-Initiated / HTTP redirect (signed)

5 Web SSO HTTP redirect / Not Federated

6SLO IdP-initiated / HTTP redirect (signed)Destroy Federation and NameIds

7 Web SSO HTTP redirect / Federate

8 MNI SP-Initiated / HTTP redirect (signed)

9 SLO SP-Initiated / HTTP redirect (signed)

10 Web SSO HTTP redirect

11 SLO IdP-Initiated / HTTP redirect (signed)

12 Encryption Disabled

Test Steps Details1. User is logged into SP. IdP enables encryption of NameId and Assertion.

IdP CONFIRM: IdP has enabled encryption for NameId and Assertion.

2. User/SP does Single Sign-On with Persistent Name Identifier and with Federate where AllowCreate is set to TRUE. SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.


10

226

227228

229

230

231

232

233

234

235

236

237

238

239240241

242243244245


IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: User has been federatedSP CONFIRM: IdP returns signed SAML Response through HTTP POST binding.

3. IdP sends signed ManageNameIdRequest message to the SP using HTTP Redirect binding. SP returns signed ManageNameIdResponse message using HTTP Redirect binding. SP Lite and IdP Lite modes omit this step.

SP CONFIRM: Receives signed ManageNameIdRequest on HTTP Redirect binding.IdP CONFIRM: Receives signed ManageNameIdResponse on HTTP Redirect binding.

4. SP sends a signed LogoutRequest message to IdP using HTTP Redirect binding. IdP logs out User session. IdP returns a signed LogoutResponse message.

IdP CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.SP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.

5. User/SP does Single Sign-On with Federation already done where AllowCreate is set to FALSE. SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.SP CONFIRM: IdP returns signed SAML Response through HTTP POST binding.

6. IdP logs out User session. IdP sends a signed LogoutRequest message to SP using HTTP Redirect binding. SP returns a signed LogoutResponse message. IdP sends signed ManageNameIdRequest message with the Terminate element to the SP using HTTP Redirect binding. Federation for User is terminated. SP returns signed ManageNameIdResponse message using HTTP Redirect binding. User logs out of session.

IdP CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.SP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.SP CONFIRM: Receives signed ManageNameIdRequest with Terminate flag on HTTP Redirect binding.SP CONFIRM: User federation is terminated.SP CONFIRM: User logs out of session.IdP CONFIRM: Receives signed ManageNameIdResponse on HTTP Redirect binding.IdP CONFIRM: User federation is terminated.IdP CONFIRM: User logs out of session.

7. User/SP does Single Sign-On with Federate where AllowCreate is set to TRUE. SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.



11

246247248249

250251252253254

255256257258

259260261262263264265

266267268269270271272273274275276277278279

280281282283284285


8. SP sends signed ManageNameIdRequest message to the IdP using HTTP Redirect binding. IdP returns signed ManageNameIdResponse message using HTTP Redirect binding. SP Lite and IdP Lite modes omit this step.

IdP CONFIRM: Receives signed ManageNameIdRequest on HTTP Redirect binding.SP CONFIRM: Receives signed ManageNameIdResponse on HTTP Redirect binding.



10. User/SP does Single Sign-On. SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.


11. IdP logs out User session. IdP sends a signed LogoutRequest message to SP using HTTP Redirect binding. SP returns a signed LogoutResponse message.

SP CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.IdP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.

12. IdP disables encryption of NameIDs and Assertions. Steps 2-11 are repeated.IDP CONFIRM: IdP has disabled encryption for NameId and Assertion.IDP/SP CONFIRM: Steps 2-11 are successfully executed.


12

286287288289290

291292293294

295296297298299300

301302303304

305306307


Test Case B – SOAP BindingPreconditions: Metadata exchanged and loadedConformance Modes: IdP, SP, IdP Lite, SP Lite


Test Step Overview Steps Action/Message/Setting

1 Encrypted IDs and Assertions

2 Web SSO Artifact / Persistent / Federate / Artifact Resolution SOAP

3 MNI IdP-Initiated / SOAP(SP may use HTTP Redirect)

4 SLO SP-Initiated / SOAP(SP Lite / IdP Lite may use HTTP Redirect)

5 Web SSO Artifact / Persistent / Not Federated / Artifact Resolution SOAP

6 SLO IdP-initiated / SOAP(SP Lite / IdP Lite may use HTTP Redirect)

7 Web SSO Artifact / Artifact Resolution SOAP

8 MNI SP-Initiated / SOAP(SP may use HTTP Redirect)

9 SLO IdP-Initiated / SOAP(SP Lite / IdP Lite may use HTTP Redirect)

10 Web SSO Artifact / Artifact Resolution SOAP

11 SLO IdP-Initiated / HTTP redirect (signed)

Test Steps Details1. User is logged into SP. IdP enables encryption of NameId and Assertions.

IdP CONFIRM: IdP has enabled encryption.

2. User/SP does Single Sign-On with Persistent Name Identifier and with Federate where AllowCreate is set to TRUE. SP communication to the IdP for the SAML Authentication Request is sent through HTTP Redirect binding. IdP provides assertion of User and IdP returns a signed SAML Response message through Artifact binding. The IdP and SP resolve the artifact via a SOAP binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: Artifact resolution is properly done.IdP CONFIRM: User has been federatedSP CONFIRM: IdP returns signed SAML Response through HTTP Artifact binding.SP CONFIRM: Artifact resolution is properly done.


13

308

309

310

311

312

312312312

313314315316317318319320321322


3. IdP sends signed ManageNameIdRequest message to the SP using SOAP binding (SP modes may use HTTP Redirect binding). SP returns signed ManageNameIdResponse message using SOAP binding. SP Lite and IdP Lite modes omit this step.

SP CONFIRM: Receives signed ManageNameIdRequest on SOAP binding (or possibly HTTP Redirect binding for SP modes).IdP CONFIRM: Receives signed ManageNameIdResponse on SOAP binding (or possibly HTTP Redirect binding for SP modes).

4. SP sends a signed LogoutRequest message to IdP using SOAP binding (SP Lite and IdP Lite modes may use HTTP Redirect binding). IdP logs out User session. IdP returns a signed LogoutResponse message.

IdP CONFIRM: Receives signed LogoutRequest on SOAP binding (or possibly HTTP Redirect binding for SP Lite and IdP Lite modes).SP CONFIRM: Receives signed LogoutResponse on SOAP binding (or possibly HTTP Redirect binding for SP Lite and IdP Lite modes).

5. User/SP does Single Sign-On with Federation already done where AllowCreate is set to FALSE. SP communication to the IdP for the SAML Authentication Request is sent through HTTP Redirect binding. IdP provides assertion of User and IdP returns a signed SAML Response message through Artifact binding. The IdP and SP resolve the artifact via a SOAP binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect Binding.IdP CONFIRM: Artifact resolution is properly done.SP CONFIRM: IdP returns signed SAML Response through HTTP Artifact binding.SP CONFIRM: Artifact resolution is properly done.

6. IdP logs out User session. IdP sends a signed LogoutRequest message to SP using SOAP binding (SP Lite and IdP Lite modes may use HTTP Redirect binding). SP returns a signed LogoutResponse message.


7. User/SP does Single Sign-On. SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User and IdP returns a signed SAML Response message through Artifact binding. The IdP and SP resolve the artifact via SOAP binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: Artifact resolution is properly done.IdP CONFIRM: User has been federatedSP CONFIRM: IdP returns signed SAML Response through HTTP Artifact binding.SP CONFIRM: Artifact resolution is properly done.


14

323324325326327328329

330331332333334335336

337338339340341342343344345

345346347345346345346

347348349350351352353354355


8. SP sends signed ManageNameIdRequest message to the IdP using SOAP binding (SP modes may use HTTP Redirect binding). IdP returns signed ManageNameIdResponse message using SOAP binding. SP Lite and IdP Lite modes omit this step.

IdP CONFIRM: Receives signed ManageNameIdRequest on SOAP binding (or possibly HTTP Redirect binding for SP modes).SP CONFIRM: Receives signed ManageNameIdResponse on SOAP binding (or possibly HTTP Redirect binding for SP modes).

9. IdP logs out User session. IdP sends a signed LogoutRequest message to IdP using SOAP binding (SP Lite and IdP Lite modes may use HTTP Redirect binding). SP returns a signed LogoutResponse message.

SP CONFIRM: Receives signed LogoutRequest on SOAP binding (or possibly HTTP Redirect binding for SP Lite and IdP Lite modes).IdP CONFIRM: Receives signed LogoutResponse on SOAP binding (or possibly HTTP Redirect binding for SP Lite and IdP Lite modes).

10. User/SP does Single Sign-On. SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User and IdP returns a signed SAML Response message through Artifact binding. The IdP and SP resolve the artifact via a SOAP binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: Artifact resolution is properly done.SP CONFIRM: IdP returns signed SAML Response through HTTP Artifact binding.SP CONFIRM: Artifact resolution is properly done.

11. IdP logs out User session. IdP sends a signed LogoutRequest message to SP using SOAP binding (SP Lite and IdP Lite modes may use HTTP Redirect binding). SP returns a signed LogoutResponse message.



15

356357358359360361362

363364365366367368369

370371372373374375376377

378379380378379378379


Test Case C – POST BindingPreconditions: Metadata exchanged and loadedConformance Modes: POST Binding


1 Encrypted Enabled

2 Web SSO / POST (signed) / Persistent / Federate

3 MNI IdP-Initiated / POST (signed)

4 SLO SP-Initiated / POST (signed)

5 Web SSO POST (signed) / Not Federated

6 SLO IdP-initiated / POST (signed)

7 Web SSO POST (signed)

8 MNI IdP-initiated / POST / Terminate


10 MNI SP-Initiated / POST (signed)

11 SLO SP-Initiated / POST (signed)


13 SLO IdP-Initiated / POST (signed)

Test Steps Details1. User is logged into SP. IdP enables encryption of NameId and Assertion.

IdP CONFIRM: IdP has enabled encryption.

2. User/SP does Single Sign-On with Persistent Name Identifier and with Federate where AllowCreate is set to TRUE. SP communication to the IdP for the SAML Authentication Request is through HTTP POST binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP POST binding.IdP CONFIRM: User has been federatedSP CONFIRM: IdP returns signed SAML Response through HTTP POST binding.

3. IdP sends signed ManageNameIdRequest message to the SP using HTTP POST binding. SP returns signed ManageNameIdResponse message using HTTP POST binding.

SP CONFIRM: Receives signed ManageNameIdRequest on HTTP POST binding.IdP CONFIRM: Receives signed ManageNameIdResponse on HTTP POST binding.

4. SP sends a signed LogoutRequest message to IdP using HTTP POST binding. IdP logs out User session. IdP returns a signed LogoutResponse message.

IdP CONFIRM: Receives signed LogoutRequest on HTTP POST binding.


16

378

378

378

378

378378378

378379380381378379378378

378379378378

378379378


SP CONFIRM: Receives signed LogoutResponse on HTTP POST binding.

5. User/SP does Single Sign-On with Federation already done where AllowCreate is set to FALSE. SP communication to the IdP for the SAML Authentication Request is through HTTP POST binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP POST binding.SP CONFIRM: IdP returns signed SAML Response through HTTP POST binding.

6. IdP logs out User session. IdP sends a signed LogoutRequest message to SP using HTTP POST binding. SP returns a signed LogoutResponse message.

IdP CONFIRM: Receives signed LogoutRequest on HTTP POST binding.SP CONFIRM: Receives signed LogoutResponse on HTTP POST binding.

7. User/SP does Single Sign-On. SP communication to the IdP for the SAML Authentication Request is through HTTP POST binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.


8. IdP sends signed ManageNameIdRequest message with the Terminate element to the SP using HTTP POST binding. User session is terminated. SP returns signed ManageNameIdResponse message using HTTP POST binding.

SP CONFIRM: Receives signed ManageNameIdRequest with Terminate flag on HTTP POST binding.SP CONFIRM: User session is terminated.IdP CONFIRM: Receives signed ManageNameIdResponse on HTTP POST binding.IdP CONFIRM: User session is terminated.



10. SP sends signed ManageNameIdRequest message to the IdP using HTTP POST binding. IdP returns signed ManageNameIdResponse message using HTTP POST binding.

IdP CONFIRM: Receives signed ManageNameIdRequest on HTTP POST binding.SP CONFIRM: Receives signed ManageNameIdResponse on HTTP POST binding.

11. SP sends a signed LogoutRequest message to IdP using HTTP POST binding. IdP logs out User session. IdP returns a signed LogoutResponse message.

IdP CONFIRM: Receives signed LogoutRequest on HTTP POST binding.


17

378

378379380381378379378

378379378378

378379380378379378

378379380378379378379380

381382383384385386

387388389390

391392393


SP CONFIRM: Receives signed LogoutResponse on HTTP POST binding.



13. IdP logs out User session. IdP sends a signed LogoutRequest message to SP using HTTP POST binding. SP returns a signed LogoutResponse message.

SP CONFIRM: Receives signed LogoutRequest on HTTP POST binding.IdP CONFIRM: Receives signed LogoutResponse on HTTP POST binding.


18

394

395396397398399400

401402403404


Test Case D – Extended SAMLModesPreconditions: Metadata exchanged and loadedConformance Modes: IdP Extended, SP Extended

Background on IdP ProxyThe IdP Proxy feature requires two IdP implementations and one SP implementation. If we have teams A and B, the following diagram depicts the roles of the test participants, assuming that IdPA and SPB are the implementations under test:

Background on Name Identifier Mapping FeatureThe name identifier mapping feature requires that an IdP provide an indirect reference for a principal at SPA in response to a request from SPB. Assuming again that teams A and B are testing IdPA and SPB, it is necessary for the principal to federate her identity at both SPB and SPA with IdPA. This can be depicted as follows:


1 Encryption Enabled

2 ProxyCount=0 (proxy disallowed)

3 Web SSO HTTP Redirect (signed) to IdPA

4 SLO SP-initiated / HTTP Redirect

5 ProxyCount missing (proxy allowed)

6 Web SSO / HTTP Redirect (signed) to IdPA


8 ProxyCount=1 (proxy allowed)


19

405

406

407

408

409

410

411

412

413

414

415

416

417


9 Web SSO / HTTP Redirect (signed)


11 Web SSO HTTP Redirect (signed) / Persistent

12 SLO IdP-initiated / HTTP Redirect

13 NameIDMappingRequest / NameIDMappingResponse

Test Steps Details1. IdPA and IdPB enables encryption of NameId and Assertion.

IdPA CONFIRM: IdPA has enabled encryption.IdPB CONFIRM: IdPB has enabled encryption.

2. SP sets ProxyCount=0 where proxy is disallowed.SP CONFIRM: SP has disallowed proxy.

3. User/SP does Single Sign-On. SP communication to the IdPA for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User and IdPA returns a signed SAML Response message through HTTP POST binding.

IdPA CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.SP CONFIRM: IdPA returns signed SAML Response through HTTP POST binding.

4. SP sends a signed LogoutRequest message to IdPA using HTTP Redirect binding. IdPA logs out User session. IdPA returns a signed LogoutResponse message.

IdPA CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.SP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.

5. SP removes ProxyCount where proxy is allowed.SP CONFIRM: SP has allowed proxy.

6. User/SP does Single Sign-On. SP communication to the IdPA for the SAML Authentication Request is through HTTP Redirect binding. IdPA proxies the Authentication Request to IdPB. IdPB provides assertion of User to IdPA in a SAML Response message through HTTP POST binding and IdPA returns a signed SAML Response message through HTTP POST binding.

IdPA CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdPB CONFIRM: IdPA proxies Authentication Request.SP CONFIRM: IdPA returns signed SAML Response through HTTP POST binding.



8. SP sets ProxyCount=1 where proxy is allowed.SP CONFIRM: SP has allowed 1 proxy.


20

418418418418

418418

418419420418419418

418419418418

418418

418419420421418419418418

418419418418

418418


9. User/SP does Single Sign-On. SP communication to the IdPA for the SAML Authentication Request is through HTTP Redirect binding. IdPA proxies the Authentication Request to IdPB. IdPB provides assertion of User to IdPA in a SAML Response message through HTTP POST binding and IdPA returns a signed SAML Response message through HTTP POST binding.

IdPA CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdPB CONFIRM: IdPA proxies Authentication Request.SP CONFIRM: IdPA returns signed SAML Response through HTTP POST binding.



11. User/SPA does Single Sign-On with Persistent Name Identifier. SPA communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SPA successfully communicated SAML Authentication Request through HTTP POST binding.IdP CONFIRM: User has been federatedSPA CONFIRM: IdP returns signed SAML Response through HTTP Redirect binding.

12. IdP logs out User session. IdP sends a signed LogoutRequest message to SPA using HTTP Redirect binding. SPA returns a signed LogoutResponse message.

SPA CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.IdP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.

13. SPB sends NameIdMapping Request message to the IdP requesting an alternative name identifier for User. IdP maps the request to the User identity from SPA. IdP returns signed NameIdMappingResponse message using HTTP POST binding.

IdP CONFIRM: Receives NameIdMapping Request.SP CONFIRM: Receives NameIdMappingResponse Response.


21

418419420421418419418418

418419418418

418419420418419418418

418419418418

418419420421422


Test Case E – IDP IntroductionPreconditions: Metadata exchanged and loadedConformance Modes: IdP, SP, IdP Lite, SP Lite


Test Step OverviewSteps Action

1 Enables Encryption / Clear Cookies2 User logins to IdPA / IdPA written to CDC 3 User logins to IdPB Login / IdPB written to CDC4 User logins to SP / SP reads cookie / User selects or redirected to IdPA 6 SLO IdPB -Initiated / HTTP Redirect7 User closes browser / CDC is removed

Test Step Detail1. Both IdPs enables encryption of NameId and Assertion. Cookies are cleared from User Browser

IdPA CONFIRM: IdPA has enabled encryption.

2. User logins at IdPA. Cookie is set in common domain with IdPA appended to list of IdPs.IdPA CONFIRM: User logged in, cookie is set in common domain and IdPA appended to end of IdP list in cookie.

3. User logins at IdPB. IdPB appended to list of IdPs in CDC.IdPB CONFIRM: User logged in and IdPB appended to end of IdP list in CDC.

4. User/SP does Single Sign-On using a common domain cookie. SP reads cookie. Depending on SP implementation, either User is presented list of IDPs and selects IdPA for authentication or SP redirects User to IdPA for authentication. SP communication to the IdPA for the SAML Authentication Request is through HTTP Redirect binding. IdPA provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.

IdPA CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.SP CONFIRM: Cookie was read and IdPA and IdPB were present in CDC.SP CONFIRM: IdPA returns signed SAML Response through HTTP POST binding.

5. SP does SLO. SP sends a signed LogoutRequest message to IdPA using HTTP Redirect binding. IdPA returns a signed LogoutResponse message. User is logged out.

IdPA CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.SP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.SP CONFIRM: User is logged out.

6. User closes browser. CDC is removed.User CONFIRM: CDC is removed once browser is closed.


22

423

424

425

426

427

428

429430

431432433

434434

434435436437438434435434434

434435436437438

439440


Test Case F – Single Session LogoutPreconditions: Metadata exchanged and loadedConformance Modes: IdP, SP, IdP Lite, SP Lite



1 Web SSO (Browser A) / Federate / HTTP Redirect

2 Web SSO (Browser B) HTTP Redirect

3 SLO (Browser A) SP-Initiated / HTTP redirect (signed)Browser B session remains active

4 Web SSO (Browser A) HTTP Redirect

5 SLO (Browser A) IdP-Initiated / HTTP redirect (signed)Browser B session remains active

6 MNI SP-initiated (Browser B) / Redirect (signed) / Terminate

Test Steps1. User A/Browser A does Single Sign-On with Federate where AllowCreate is set to TRUE. SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User A and IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: User A has been federated.IdP CONFIRM: User A has been logged in through Browser A (Session A).SP CONFIRM: IdP returns signed SAML Response through HTTP POST binding.

2. User A/Browser B does Single Sign-On. SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User B and IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: User B has been logged in through Browser B (Session B).SP CONFIRM: IdP returns signed SAML Response through HTTP POST binding.

3. User A/Browser A logs off of SP. SP sends a signed LogoutRequest message to IdP using HTTP Redirect binding. IdP logs out User A in Browser A (Session A). User A remains logged in through Browser B (Session B). IdP returns a signed LogoutResponse message.

IdP CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.IdP CONFIRM: User A logs out in Browser A (Session A).IdP CONFIRM: User A is logged in through Browser B (Session B).SP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.


23

441

442

443

444

445

446447448449450451452453454455

456457458459460459459

459460461459459459459


SP CONFIRM: User A logs out in Browser A (Session A).IdP CONFIRM: User A is logged in through Browser B (Session B).

4. User A/Browser A does Single Sign-On. SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User A and IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: User A has been logged in through Browser A (Session A).SP CONFIRM: IdP returns signed SAML Response through HTTP POST binding.

5. User A/Browser A logs off of IdP. IdP sends a signed LogoutRequest message to SP using HTTP Redirect binding. SP logs out User A in Browser A (Session A). User A remains logged in through Browser B (Session B). SP returns a signed LogoutResponse message.

SP CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.SP CONFIRM: User A logs out in Browser A (Session A).SP CONFIRM: User A is logged in through Browser B (Session B).IdP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.IdP CONFIRM: User A logs out in Browser A (Session A).IdP CONFIRM: User A is logged in through Browser B (Session B).

6. SP sends signed ManageNameIdRequest message with the Terminate element to the IdP using HTTP Redirect binding. Federation for User A is terminated. IdP returns signed ManageNameIdResponse message using HTTP Redirect binding. User A logs out of Browser B (Session B).

IdP CONFIRM: Receives signed ManageNameIdRequest with Terminate flag on HTTP Redirect binding.IdP CONFIRM: Federation of User A is terminated.IdP CONFIRM: User A is logged out in Browser B (Session B).SP CONFIRM: Receives signed ManageNameIdResponse on HTTP Redirect binding.SP CONFIRM: Federation of User A is terminated.SP CONFIRM: User A is logged out in Browser B (Session B).


24

459460

461462463464465466467

468469470471472473474475476

477478479480481482483484485486487


Test Case G – Unsolicited <Response>Preconditions: Metadata exchanged and loadedConformance Modes: IdP, SP, IdP Lite, SP Lite


1 IdP Unsolicited SSO Response / Transient / HTTP POST (signed)2 SLO SP-Initiated / HTTP redirect (signed)

3IdP Unsolicited SSO Response / Transient / HTTP artifact / Artifact

Resolution (SOAP)4 SLO IdP-Initiated / HTTP redirect (signed)

Test Step Detail1. User/IdP does Single Sign-On. IdP provides assertion of User and Name ID is Transient. IdP sends a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: User has been federatedSP CONFIRM: IdP sends signed SAML Response through HTTP POST binding.



3. User/IdP does Single Sign-On. IdP provides assertion of User and Name ID is Transient. IdP sends a signed SAML Response message through HTTP Artifact using an HTTP Redirect URL. The IdP and SP resolve the artifact via a SOAP binding.

IdP CONFIRM: Artifact resolution is properly done.IdP CONFIRM: User has been federatedSP CONFIRM: IdP sends signed SAML Response through HTTP Artifact.SP CONFIRM: Artifact resolution is properly done.

4. IdP sends a signed LogoutRequest message to SP using SOAP binding. SP logs out User session. SP returns a signed LogoutResponse message.

SP CONFIRM: Receives signed LogoutRequest on SOAP binding.IdP CONFIRM: Receives signed LogoutResponse on SOAP binding.


25

488

489

490

491

492

493494495496

497498499500

501502503504504504504

504505504504


Test Case H – AffiliationsPreconditions: Metadata exchanged and loadedConformance Modes: IdP, SP, IdP Lite, SP Lite


1 SPNameQualifier=[affiliation id]2 Web SSO HTTP Redirect / Persistent / Federate3 SLO IdP-initiated / HTTP Redirect (signed)4 Web SSO HTTP Redirect / Not Federate5 SLO SP-initiated / HTTP Redirect (signed)6 SPNameQualifier=[sp provider id]

Test Step Detail1. SP sets Name Qualifier to Affiliation ID.

SP CONFIRM: SPNameQualifier=[affiliation id]

2. User/SP does Single Sign-On with Persistent Name Identifier and with Federate where AllowCreate is set to TRUE. SP communication to the IdP for the SAML Authentication Request is through HTTP POST binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.


3. IdP logs out User session. IdP sends a signed LogoutRequest message to SP using HTTP Redirect binding. SP returns a signed LogoutResponse message.

SP CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.IdP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.

4. User/SP does Single Sign-On with Federation already done where AllowCreate is set to FALSE. SP communication to the IdP for the SAML Authentication Request is through HTTP POST binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.





26

504

504

504

504

504

504504

504505506507504505504504

504505504504

504505506507504505504

504505504504


6. SP sets Name Qualifier to SP Provider ID.SP CONFIRM: SPNameQualifier=[sp provider id]NOTE: It is recommended that the SP verifies it has changed back the SPNameQualifier through a SSO/SLO test with other participants.


27

504505506507


Test Case I – Multiple SP LogoutPreconditions: Metadata exchanged and loadedConformance Modes: IdP, SP, IdP Lite, SP Lite


1 User A Web SSO to IdP through SPA

2 User A logins to SPB and authenticated by IdP (same session id)3 SLO SPA-initiated to IdP4 IdP-initiated LogoutRequest to SPB / session ends5 User A Web SSO to IdP through SPB

6 User A logins to SPA and authenticated by IdP (same session id)7 SLO IdP-initiated to SPB

8 IdP-initiated LogoutRequest to SPA / session ends

Test Step Detail1. User A at SPA performs Single Sign-On (any profile) to IdP.

IdP CONFIRM: SPA successfully communicated SAML Authentication Request and IdP sent back Assertion for User A.IdP CONFIRM: User has been federated.SPA CONFIRM: IdP returns signed SAML Response and User A is authenticated.

2. User A logins to SPB and is authenticated by IdP with same session id. IdP CONFIRM: SPB successfully communicated SAML Authentication Request and IdP sent back Assertion for User A and maintained same session id as in Step 1.SPB CONFIRM: IdP returns signed SAML Response and User A is authenticated.

3. User A does SSO from SPA to IdP. IdP CONFIRM: SPA sends LogoutRequest for User A and a LogoutResponse is returned. SPA CONFIRM: A LogoutRequest is sent to IdP, IdP returns a LogoutResponse and User A is logged out.

4. LogoutRequest is sent to SPB from IdP. User is logged out of SPB and federation is ended. IdP CONFIRM: LogoutRequest is sent to SPA and receives back LogoutResponse. IdP CONFIRM: Federation for User A is ended.SPB CONFIRM: IdP sends LogoutResponse, a LogoutResponse is returned and User A is logged out.

5. User A at SPB performs Single Sign-On (any profile) to IdP. IdP CONFIRM: SPB successfully communicated SAML Authentication Request and IdP sent back Assertion for User A.IdP CONFIRM: User has been federated.SPB CONFIRM: IdP returns signed SAML Response and User A is authenticated.


28

508

509

510

511

512

513514515516517

518519520521

522523524525

526527528529530

531532533534535


6. User A logins to SPA and is authenticated by IdP with same session id. IdP CONFIRM: SPA successfully communicated SAML Authentication Request and IdP sent back Assertion for User A and maintained same session id as in Step 5.SPA CONFIRM: IdP returns signed SAML Response and User A is authenticated.

7. User A does SSO from IdP to SPB. IdP CONFIRM: SPB is sent LogoutRequest for User A and a LogoutResponse is returned. SPB CONFIRM: IdP sends a LogoutRequest, a LogoutResponse is returned and User A is logged out.

8. LogoutRequest is sent to SPA from IdP. User is logged out of SPA and federation is ended. IdP CONFIRM: LogoutRequest is sent to SPA and receives back LogoutResponse. IdP CONFIRM: Federation for User A is ended.SPA CONFIRM: IdP sends LogoutResponse, a LogoutResponse is returned and User A is logged out.


29

536537538539

540541542543

544545546547548


Test Case J – Force Authentication and Passive AuthenticationPreconditions: Metadata exchanged and loadedConformance Modes (Required): IdP, IdP LiteConformance Modes (Optional): SP, SP LiteNOTE: Support of IsPassive and ForceAuthn is optional for SP and SP Lite products.


1 User logins to IdP to create active session.2 Configure SP to make IsPassive=TRUE3 Web SSO HTTP redirect / IdP authenticates user without user login4 SLO SP-initiated to IdP5 Configure SP to make IsPassive=FALSE6 Web SSO HTTP redirect / User logins at IdP / User is authenticated7 SLO SP-initiated to IdP8 User logins to IdP to create active session.9 Configure SP to make ForceAuthn=TRUE10 Web SSO HTTP redirect / User logins at IdP / User is authenticated11 SLO SP-initiated to IdP

Test Step Detail1. User logins at IdP and creates and active session

IdP CONFIRM: User logged in.

2. SP is configured to make IsPassive set to TRUE.SP CONFIRM: SP is configured IsPassive=TRUE.

3. User/SP does Single Sign-On SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP provides assertion of User without interacting with the user. IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: User does not interact with IdP.SP CONFIRM: IdP returns assertion in signed SAML Response through HTTP POST binding.


IdP CONFIRM: Receives signed LogoutRequest on HTTP Redirect binding.SP CONFIRM: Receives signed LogoutResponse on HTTP Redirect binding.SP CONFIRM: User is logged out.

5. SP is configured to make IsPassive set to FALSE.SP CONFIRM: SP is configured IsPassive=FALSE.


30

549

550

551

552

553

554

555

556557

558559

560561562563564565566

567568569570571

572573


6. User/SP does Single Sign-On SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP interacts with and authenticates the user. IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: User does interact with IdP.SP CONFIRM: IdP returns assertion in signed SAML Response through HTTP POST binding.



8. User logins at IdP and creates and active sessionIdP CONFIRM: User logged in.

9. SP is configured to make ForceAuthn set to TRUE.SP CONFIRM: SP is configured IsPassive=TRUE.

10. User/SP does Single Sign-On SP communication to the IdP for the SAML Authentication Request is through HTTP Redirect binding. IdP interacts with User and authenticates the User. IdP provides assertion of User. IdP returns a signed SAML Response message through HTTP POST binding.

IdP CONFIRM: SP successfully communicated SAML Authentication Request through HTTP Redirect binding.IdP CONFIRM: User interacts with IdP and is authenticated.SP CONFIRM: IdP returns assertion in signed SAML Response through HTTP POST binding.




31

574575576577578579580

581582583583583

583583

583583

583584585583584585586

587588589590591


Test Case K – ECPPreconditions: Metadata exchanged and loadedConformance Modes: IdP, SP, IdP Lite, SP Lite, ECP


1 Federate (NameIDPolicy, AllowCreate=True)2 Enhanced ClientProxy SSO, PAOS3 ECP conveys Response to SP

Test Step Detail1. User attempts to access SP through ECP. Settings are Persistent Name Identifier and with Federate where AllowCreate is set to TRUE to SP.

ECP CONFIRM: Connects to SP.SP CONFIRM: ECP connects.

2. SP issues SAML AuthnRequest message to ECP through PAOS binding. ECP sends SAML Request message to IdP through SOAP binding. IdP returns assertion in SAML Response to ECP.

IdP CONFIRM: ECP successfully communicated SAML Authentication Request through SOAP binding.SP CONFIRM: IdP returns signed SAML Response through HTTP SOAP binding.

3. ECP conveys Response to SP. SP grants access to User. User closes browser and session ends. SP CONFIRM: Proper Response is received.ECP CONFIRM: User is granted access to SP.


32

592

592

592

592

592

592593592592

592593592593592

592592592


Test Case L – SAML Authentication AuthorityConformance Modes: SAML Authentication AuthorityPreconditions: Metadata exchanged and loadedNote: Section [AuthenticationContexts] within this document describes the strength of the AuthnContext classes used for comparison.


1 Web SSO / POST (signed) / Persistent

2 AC Comparison=”exact” / HTTP Basic Authentication

3 Authentication Query / SOAP

4 AC Comparison=”better”


6 AC Comparison=”minimum”


8 AC Comparison=”maximum”


Test Step Detail1. User/SP does Single Sign-On with Persistent Name Identifier. SP communication to the IdP for the SAML Authentication Request is through HTTP POST binding. IdP provides assertion of User and IdP returns a signed SAML Response message through HTTP POST binding.


2. SAML Requester sets AC comparison to “exact”. SAML Requester/Responder enables HTTP Basic Authentication.

SAML Requester CONFIRM: AC comparison=”exact”.SAML Requester CONFIRM: HTTP Basic Authentication enabled.SAML Responder CONFIRM: HTTP Basic Authentication enabled.

3. SAML Requester sends Authentication Query to SAML Responder through SOAP binding. SAML Responder returns SAML Response.

SAML Responder CONFIRM: SAML Requester sent Authentication Query.SAML Requester CONFIRM: SAML Responder returned the SAML Response.

4. SAML Requester sets AC comparison to “better”. SAML Requester CONFIRM: AC comparison=”better”.


33

592

592

592

592

593

594

594

594595596594595594594

594595594594594

594595594594

594594




6. SAML Requester sets AC comparison to “minimum”. SAML Requester CONFIRM: AC comparison=”minimum”.



8. SAML Requester sets AC comparison to “maximum”. SAML Requester CONFIRM: AC comparison=” maximum”.




34

594595594594

594594

594595594594

594594

594595594594


Test Case M – SAML Attribute AuthorityConformance Modes: SAML Attribute AuthorityPreconditions: Metadata exchanged and loaded

Test Step Overview

Steps Action/Message/Setting1 Web SSO / POST (signed) / Persistent

2 Attribute Query No Attributes

3 Attribute Query / SOAP

4 Attribute Query Attribute Named


6 Attribute Query Attribute Value


8 Encrypted Attribute / Attribute Query Attribute Named




2. SAML Responder sets attribute query to no attributes.SAML Responder CONFIRM: Attribute Query No Attributes.

3. SAML Requester sends Attribute Query to SAML Responder through SOAP binding. SAML Responder returns SAML Response.

SAML Responder CONFIRM: SAML Requester sent Attribute Query.SAML Requester CONFIRM: SAML Responder returned the SAML Response.

4. SAML Responder sets attribute query to attribute named.SAML Responder CONFIRM: Attribute Query Attribute Named.




35

594

594

594

594

594

594595596594595594594

594594

594595594594

594594

594595594594


6. SAML Responder sets attribute query to attribute value.SAML Responder CONFIRM: Attribute Query Attribute Value.



8. SAML Responder sets attribute query to attribute named. SAML Responder enables attribute for encryption.

SAML Responder CONFIRM: Attribute Query Attribute Named.SAML Responder CONFIRM: Encryption assertion enabled.




36

594594

594595594594

594595594594

594595594594


Test Case N – SAML Authorization Decision AuthorityConformance Modes: SAML Authorization Decision AuthorityPreconditions: Metadata exchanged and loaded


1 Web SSO / POST (signed) / Persistent

2 HTTP Basic Authentication

3 AuthzQuery Resource=never (never permitted)

4 Authorization Decision Query / SOAP

5 AuthzQuery Resource=maybe (permitted if auth match)


7 AuthzQuery Resource=always (always permitted)




2. SAML Requester enables HTTP Basic Authentication.SAML Requester CONFIRM: HTTP Basic Authentication enabled.

3. SAML Responder sets Authorization Query to never permitted which means subject is never authorized for access.

SAML Responder CONFIRM: AuthzQuery Resource=never

4. SAML Requester sends Authorization Query to SAML Responder through SOAP binding. SAML Responder returns SAML Response.

SAML Responder CONFIRM: SAML Requester sent Authorization Query.SAML Requester CONFIRM: SAML Responder returned the SAML Response.

5. SAML Responder sets authorization query to maybe permitted if authentication is matched which means subject is authorized if it is a “particular” subject.

SAML Responder CONFIRM: AuthzQuery Resource=maybe



37

594

594

594

594

594

594595596594595594594

594594

594595594

594595594594

594595594

594595



7. SAML Responder sets Authorization Query to always permitted which means subject is always authorized.

SAML Responder CONFIRM: AuthzQuery Resource=always




38

594594

594595594

594595594594


Test Case O – SAML URI BindingConformance Modes: SAML Attribute Authority, SAML Authorization Decision Authority, SAML Authentication Authority, SAML RequesterPreconditions: Metadata exchanged and loaded



2 Request for Assertion by Identifier / SOAP


4 SAML URI Binding

Test Step Detail1. Requester enables HTTP Basic Authentication

Requester CONFIRM: HTTP Basic Authentication enabled.

2. Requester sends SAML Request message to Responder in SOAP over HTTP. Request message contains <AssertionIDRequest> and HTTP basic authentication. Assertion ID is assigned at test time. Responder returns identified <Assertion> in SAML Response in SOAP over HTTP.

Requester and Responder CONFIRM: Use SOAP over HTTPRequester and Responder CONFIRM: Use HTTP basic authentication.Requester and Responder CONFIRM: Request message contains <AssertionIDRequest> for assigned assertion ID.Requester and Responder CONFIRM: Response message contains identified <Assertion>.

3. Requester enables HTTP Basic Authentication Requester CONFIRM: HTTP Basic Authentication enabled.

4. Requester sends HTTP GET message to Responder with URI containing assertion ID. Assertion ID assigned at test time. HTTP GET message contains HTTP basic authentication. Responder returns HTTP response with SAML Response containing assigned <Assertion>.

Requester and Responder CONFIRM: Use HTTP basic authentication.Requester and Responder CONFIRM: HTTP GET URI contains assigned assertion ID.Requester and Responder CONFIRM: Assigned <Assertion> is returned in response.


39

594

594

595

594

594

594

594594

594595596594594594595594

594594

594595596594594594


Test Case P – Error TestingConformance Modes: IdP, SP, SP LitePreconditions: Metadata exchanged and loaded


1 Artifact Refused

2 Successful Response Message

3 Repost of Assertion

4 Altered data, signature mismatch

5 Wrong key used to sign

6 SubjectConfirmation Recipient !=assertion service consumer URL

7 Unknown SubjectConfirmationMethod

8 IncorrectAudienceRestriction != requestor

9 SubjectConfirmation NoOnOrAfter expired

10 Unknown Condition

Test Step Detail

NOTE – Test Steps 2-9 involve the Liberty Error Test Tool. Metadata for conducting these tests will be exchanged.

2. Test Harness POSTs an unsolicited SAML Response message containing a valid assertion.SP CONFIRM: SAML Response was received and assertion accepted.

3. Test Harness re-POSTs the assertion that was successful during the initialization of this test sequence.

SP CONFIRM: Assertions are not replayed within the validity period of the assertion.

4. The assertion of the SAML Response from Step 2 is altered and sent without re-signing in a HTTP POST from Test Harness.

SP CONFIRM: SP rejects the message.

5. The assertion of the SAML Response from Step 2 is sent but signed with the wrong signing key in a HTTP POST from Test Harness.

SP CONFIRM: SP rejects the message.

6. The Test Harness constructs a SAML Response message with an incorrect Recipient attribute. Recipient attribute is in the <SubjectConfirmationData> element.

SP CONFIRM: SP detects and rejects the message.


40

594

594

594

594

594

594595

594594

594595594

594595594

594595594

594595594


7. The Test Harness sends an altered assertion in the SAML Response. A different Method URN is substituted in the assertion’s <SubjectConfirmation> element other than the required Method of urn:oasis:names:tc:SAML:2.0:cm:bearer.

SP CONFIRM: SP detects and rejects the message.

8. The Test Harness POSTs a SAML Response containing an assertion which does not contain an <AudienceRestriction> including the SP's unique identifier as an <Audience>.

SP CONFIRM: SP rejects the assertion.

9. The Test Harness sets the NotOnOrAfter attribute to a future value that has passed.SP CONFIRM: The SP to reject the assertion because of the NotOnOrAfter attribute.

10. The Test Harness includes a <Condition> extension element in the <Conditions> element of the assertion that cannot be understood.

SP CONFIRM: The SP rejects the assertion.


41

594595596594

594595594

594594

594595594


Test Case Q – eGov ProfilePreconditions: Metadata exchanged and loadedConformance Modes: IdP, SP


1 Web SSO AuthnRequest / HTTP Redirect (signed)

2 Web SSO AuthnResponse / HTTP POST (signed)

3 SLO SP-initiated / HTTP Redirect(signed)

4 IdP Discovery

5 Multiple SP Logout

6 Force Authentication and IsPassive

Pre-Test Setup1. TLS certificates MUST be trusted by default in commonly used browsers. Certificates and security toolkits MUST follow GSA requirements.2. eGov approved FIPS certificates must be installed.

Test Steps Details1. SP sends a SAML Authentication Request to the IdP through HTTP Redirect binding. Authentication Request must be signed and delivered over TLS. The following list contains either requirements for the request which must occur, conditional actions which if done must be handled in a specific way or optional conditions which may or may not be done.

<AuthnRequest>REQUIRED: <Issuer> MUST be present, MUST be the identifier of the SP and MUST be a URL within the SP domain.CONDITIONAL: ProtocolBinding is optional but if present it MUST be urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST.CONDITIONAL: <RequestedAuthnContext> MAY be included in authentication request but if present, the Comparison attribute MUST be set to minimum.OPTIONAL: IsPassive MAY be used.OPTIONAL: Within <NameIDPolicy>, AllowCreate attribute MAY be present.CONDITIONAL: SP MAY set ForceAuthn to true. If FoceAuthn is set to TRUE, IsPassive MUST either be omitted or set to FALSE.CONDITIONAL: If SP sets ForceAuthn to true, IdP MUST authenticate regardless of user’s authentication session status.CONDITIONAL: Within <NameIDPolicy>, if Format is present, it MUST use one of the following:

urn:oasis:names:tc:SAML:2.0:nameid-format:persistenturn:oasis:names:tc:SAML:2.0:nameid-format:transient


42

594

595

596

597

598598599598

598598599600601598598599598599598599598598598599598599598599598598


2. IdP returns the Authentication Response with the assertion to the SP through HTTP POST binding over TLS to the SP’s <Assertion> Consumer Service. The following list contains either requirements for the request that must occur or optional conditions that may be done.

<Response>REQUIRED: Version attribute MUST be set to “2.0”.REQUIRED: Each <Response> MUST contain no more than one <EncryptedAssertion>.CONDITIONAL: Consent attribute MAY be used, but if used MUST use one of the following:

urn:oasis:names:tc:SAML:2.0:consent:obtainedurn:oasis:names:tc:SAML:2.0:consent:priorurn:oasis:names:tc:SAML:2.0:consent:current-impliciturn:oasis:names:tc:SAML:2.0:consent:current-expliciturn:oasis:names:tc:SAML:2.0:consent:unspecified

<Assertion> element within the <Response>REQUIRED: An <Assertion> MUST be returned within <EncryptedAssertion> by the IdP and MUST be signed and encrypted. REQUIRED: Version MUST be 2.0.REQUIRED: <Issuer> MUST be present, MUST be the identifier of the IdP and MUST be a URL reference within the domain of the IdP.REQUIRED: There MUST be exactly one <Subject> per <Assertion>.

<Subject> element within the <Assertion>REQUIRED: An <Assertion> MUST contain exactly one <Subject> indicating the end user to which <Assertion> pertains. REQUIRED: <NameID> MUST contain a Format attribute set either:

urn:oasis:names:tc:SAML:2.0:nameid-format:persistenturn:oasis:names:tc:SAML:2.0:nameid-format:transient

<AuthnStatement> element within the <Assertion>REQUIRED: <AuthnStatement> MUST include the SessionIndex of the end user. OPTIONAL: <AuthnStatement> MAY contain SessionNotOnOrAfter but SP is NOT REQUIRED to honor SessionNotOnOrAfter.

<AttributeStatement> element within the <Assertion>REQUIRED: The first transmission of an <Assertion> MUST contain exactly one <AttributeStatement> for a particular <Subject>. Each subsequent <Assertion> MUST contain no more than one <AttributeStatement>.REQUIRED: Each <Attribute MUST not be encrypted.CONDITIONAL: If present, NameFormat of <Attribute> MUST be one of the following:

urn:oasis:names:tc:SAML:2.0:attrname-format:unspecifiedurn:oasis:names:tc:SAML:2.0: attrname-format:uriurn:oasis:names:tc:SAML:2.0: attrname-format:basic


43

598599600598598598599598599598598598598598

598598599598598599598

598598599598598598

598598598599

598599600601602603604605606607


REQUIRED: <Attribute> Name MUST be a URI.CONDITIONAL: Where the definition of an attribute includes one or more descriptors for the attribute, FriendlyName, if present, MUST be one of the defined descriptors.

CONDITIONAL: If <AuthnStatement> accompanies <AttributeStatement>, the following attributes MUST be present and follow the specified format• us:gov:e-authentication:basic:assuranceLevel MUST be one of 1, 2, 3, 4, or test and use

datatype of xs:string.• urn:oid:2.5.4.3 MUST have first name followed by optional middle name or initial

followed by last name delimited by spaces and MUST be <=256 characters in length and use datatype of xs:string.

• us:gov:e-authentication:basic:specVer MUST be “2.0” for this interface specification and use datatype of xs:string.:

CONDITIONAL: These attributes are optional but may provide a richer attribute set for end user.• urn:oid:2.5.4.4 MUST be <=128 characters in length and of datatype xs:string.• urn:oid:2.5.4.42 MUST be <=128 characters in length and of datatype xs:string.• urn:oid:1.3.6.1.4.1.1466.101.120.34 MUST be <=128 characters in length and of datatype

xs:string.• urn:oid: 2.5.4.44 MUST be <=20 characters in length and of datatype xs:string.• us:gov:e-authentication:basic:PSSN MUST be 4 digits and of datatype xs:integer.• us:gov:e-authentication:basic:birthMonth MUST be 2 digits and MUST contain a value in

the range of 01 - 12 and of datatype xs:integer.• us:gov:e-authentication:basic:birthDay MUST be 2 digits and MUST contain a value in the

range of 01 – 31 and of datatype xs:integer.• us:gov:e-authentication:basic:birthYear MUST be 4 digits (yyyy) and of datatype

xs:integer.• us:gov:e-authentication:basic:address1 MUST be <= 50 characters in length and of

datatype xs:string.• us:gov:e-authentication:basic:address2 MUST be <= 50 characters in length and of

datatype xs:string.• urn:oid:2.5.4.7 MUST be <= 28 characters in length and of datatype xs:string.• urn:oid:2.5.4.8 MUST be 2 character length state code and of datatype xs:string.• urn:oid:2.5.4.17 MUST be either 5 digit format or 5digit-4digit (including the dash) format

and of datatype xs:string .• us:gov:e-authentication:basic:Sid MUST be <= 128 characters in length and of datatype

xs:string.

3. SP sends a signed LogoutRequest message to IdP over TLS 1.0 using HTTP Redirect binding. IdP logs out User session. IdP returns a signed LogoutResponse message over TSL 1.0 using the HTTP Redirect binding.

<Logout Request>REQUIRED: Version attribute MUST be set to “2.0”.

<Logout Response>Liberty Alliance Project

44

608609610

611612613

614615

616617618

619

620621622

623

624

625626

627

628

629630

631632

633634

635636

637638

639

640

641642

643

644645646647648649


REQUIRED: Version attribute MUST be set to “2.0”.

4. SP and IdP execute Test Case E as described in the test case except for in step D.4, SP reads CDC and displays both IdPs and User selects IdPA

SP CONFIRM: Test Case E is executed as expected.SP CONFIRM: CDC is read and both IdPs are displayed for User selection.IdP CONFIRM: Test Case E is executed as expected.

5. SP and IdP execute Test Case I, Multiple SP Logout.SP CONFIRM: Test Case I is executed as expected.IdP CONFIRM: Test Case I is executed as expected.

6. SP and IdP execute Test Case J, Force Authentication and IsPassive.SP CONFIRM: Test Case J is executed as expected.IdP CONFIRM: Test Case J is executed as expected.


45

650

651652653654655

656657658

659660661


References[SAMLTP30] Kyle Meadors, et al, “SAML 2.0 Interoperability Testing Procedures, V3.0,

Errata J,” Liberty Alliance Project (November 2007), http://www.projectliberty.org/liberty/content/download/3957/26509/file/Liberty_DGI_4Q07_Interoperability_SAML_Test_Criteria_Test_Plan_vs.3.0.Errata.J.pdf

[ExcXMLCan] John Boyer et al, “Exclusive XML Canonicalization Version 1.0, W3C Recommendation”, W3C (July 2002), http://www.w3.org/TR/xml-exc-c14n/

[SAMLAuthnCxt] J. Kemp et al, “Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS SSTC (March 2005), http:// docs.oasis- open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf.

[SAMLBind] Scott Cantor et al, “Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS SSTC (March 2005), http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

[SAMLConf] Prateek Mishra et al, “Conformance Requirements for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS SSTC (March 2005). http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf.

[SAMLCore] S. Cantor et al, “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS SSTC (March 2005), http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.

[SAMLErrata] Jahan Moreh, “Errata for the OASIS Security 2 Assertion Markup Language (SAML) V2.0, Working Draft 28,” OASIS SSTC (May 8, 2006), http://www.oasis-open.org/committees/download.php/18070/sstc-saml-errata-2.0-draft-28.pdf

[SAMLLDAP] S. Cantor et al, “SAML V2.0 X.500/LDAP Attribute Profile,” OASIS SSTC (December 19, 2006), http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-attribute-x500-cd-01.pdf

[SAMLMeta] S. Cantor et al, “Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS SSTC (March 2005), http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.

[SAMLMetaExt] Tom Scavo et al, “SAML Metadata Extension for Query Requesters, Committee Draft 01”, OASIS SSTC (March 2006), http://www.oasis-open.org/committees/download.php/18052/sstc-saml-metadata-ext-query-cd-01.pdf

[SAMLProf] S. Cantor et al, “Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS SSTC (March 2005), http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf.

[SAMLSec] Frederick Hirsch et al, “Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS SSTC (March 2005), http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf


46

662

663664665666667

668669

670671672

673674675

676677678

679680681

682683684685

686687688

689690691

692693694

695696697

698699700701

http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf

http://www.oasis-open.org/committees/download.php/18070/sstc-saml-errata-2.0-draft-28.pdf

http://www.oasis-open.org/committees/download.php/18070/sstc-saml-errata-2.0-draft-28.pdf


[GSATechAppr] Dave Silver et al, “Technical Approach for the Authentication Service Component” vs. 2.0.0 GSA (May 2007), http://www.cio.gov/eauthentication/TechnicalArchitecture.htm

[GSAAdoptSchm] Dave Silver et al, “E-Authentication Federation Adopted Schemes” vs. 1.0.0 GSA (May 2007), http://www.cio.gov/eauthentication/TechnicalArchitecture.htm

[GSAInterface] Dave Silver et al, “E-Authentication Federation Architecture 2.0 Interface Specifications” vs. 1.0.0 GSA (May 2007), http://www.cio.gov/eauthentication/TechnicalArchitecture.htm


47

702703704

705706707

708709710

http://www.cio.gov/eauthentication/TechnicalArchitecture.htm



saml 2.0 interop test plan - liberty alliance · test plan for liberty alliance saml test event...

Documents