SAML 2.0 Interop Test Plan - Liberty ?· Test Plan for Liberty Alliance SAML Test Event Test Criteria…

Download SAML 2.0 Interop Test Plan - Liberty ?· Test Plan for Liberty Alliance SAML Test Event Test Criteria…

Post on 08-Aug-2018

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

<ul><li><p>Test Plan for Liberty Alliance SAML Test EventTest CriteriaSAML 2.0Version 3.1</p><p>Editor:</p><p>Kyle Meadors, Drummond Group Inc.</p><p>Abstract:This document describes the test steps to achieve the Liberty Interoperable designation for various SAML 2.0 modes and profiles.</p><p>Filename: Liberty_Interoperability_SAML_Test_Plan_v3.1.odt</p><p>1</p><p>2</p><p>3</p><p>4</p><p>5</p><p>6</p><p>7</p><p>89</p><p>10</p><p>11</p></li><li><p>Liberty Alliance Project Version 3.1SAML 2.0 Test Steps</p><p>ContentsIntroduction.....................................................................................................................................3</p><p>Overview of Test Plan.......................................................................................................................3Test Plan History...............................................................................................................................3SAML Conformance Modes..............................................................................................................3eGov Profile.......................................................................................................................................4POST Binding....................................................................................................................................4</p><p>Technical Requirements................................................................................................................5Metadata............................................................................................................................................5IdP Authentication.............................................................................................................................5Trivial Processing..............................................................................................................................5Authentication Contexts.....................................................................................................................5Name Identifier Formats....................................................................................................................6XML Signatures.................................................................................................................................6XML Encryption................................................................................................................................7Attribute Profiles...............................................................................................................................7Consensus Items................................................................................................................................7</p><p>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 ...........................................................................................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</p><p>References......................................................................................................................................46</p><p>Liberty Alliance Project</p><p>2</p><p>121314151617181920212223242526272829303132333435363738394041424344454647484950</p></li><li><p>Liberty Alliance Project Version 3.1SAML 2.0 Test Steps</p><p>Introduction</p><p>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. </p><p>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].</p><p>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.</p><p>Test Plan HistoryThis 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.</p><p> SAML 2.0 Interoperability Testing Procedure, vs. 3.0.J (11/20/2007)</p><p> SAML 2.0 Interoperability Testing Procedure, vs. 2.0 (07/07/2006)</p><p> SAML 2.0 Interoperability Testing Procedure, vs. 1.0 (2005)</p><p>SAML Conformance ModesThis 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:</p><p> IdP Identity Provider</p><p> IdP Lite Identity Provider Lite</p><p> SP Service Provider</p><p> SP Lite Service Provider Lite</p><p> ECP Enhanced Client/Proxy</p><p> IdP Extended Identify Provider Extended</p><p> SP Extended Service Provider Extended</p><p> SAML Attribute Authority </p><p> SAML Authorization Decision AuthorityLiberty Alliance Project</p><p>3</p><p>51</p><p>52</p><p>535455</p><p>56575859</p><p>6061626364</p><p>65</p><p>666768</p><p>69</p><p>70</p><p>71</p><p>72</p><p>737475</p><p>76</p><p>77</p><p>78</p><p>79</p><p>80</p><p>81</p><p>82</p><p>83</p><p>84</p></li><li><p>Liberty Alliance Project Version 3.1SAML 2.0 Test Steps</p><p> SAML Authentication Authority </p><p> SAML Requester</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>Liberty Alliance Project</p><p>4</p><p>85</p><p>86</p><p>878889</p><p>9091</p><p>92939495</p><p>96</p><p>979899</p><p>100</p><p>101</p><p>102103104105</p></li><li><p>Liberty Alliance Project Version 3.1SAML 2.0 Test Steps</p><p>Technical Requirements</p><p>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:</p><p> Furnish correct metadata, and</p><p> Process metadata furnished by other testing partners </p><p>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.</p><p>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:</p><p>1. HTTP Basic Auth.2. HTTP Form Post3. HTTP Get</p><p>Similarly, it is required that user agents, particularly ECP implementations, be able to authenticate using at least one of these methods.</p><p>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.</p><p>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: </p><p>1. any defined authentication context not listed below</p><p>2. urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession</p><p>3. urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol</p><p>Liberty Alliance Project</p><p>5</p><p>106</p><p>107</p><p>108109110</p><p>111</p><p>112</p><p>113114115116</p><p>117</p><p>118119120121</p><p>122123124125126</p><p>127</p><p>128129130131132</p><p>133</p><p>134135136137138</p><p>139</p><p>140</p><p>141</p></li><li><p>Liberty Alliance Project Version 3.1SAML 2.0 Test Steps</p><p>4. urn:oasis:names:tc:SAML:2.0:ac:classes:Password</p><p>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.</p><p>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.</p><p>Name Identifier FormatsThe following Name Identifier Formats are defined by [SAMLCore]:</p><p>1. Unspecified</p><p>2. Email</p><p>3. X.509 Subject</p><p>4. Windows</p><p>5. Kerberos</p><p>6. Entity</p><p>7. Persistent</p><p>8. Transient</p><p>Every implementation is required to accept messages containing any of these formats, but [SAMLCore] only requires that the last two be processed.</p><p>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:</p><p>1. Web SSO: The assertion element(s) in the MUST be signed for the HTTP POST binding.</p><p>2. ECP Profile: The assertion element(s) in the issued by the IdP MUST be signed.</p><p>3. Single Logout: The and MUST be signed for the HTTP redirect binding.</p><p>4. Name Identifer Management: The and MUST be signed for the HTTP redirect binding.</p><p>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.</p><p>Liberty Alliance Project</p><p>6</p><p>142</p><p>143144145146</p><p>147148149</p><p>150</p><p>151</p><p>152</p><p>153</p><p>154</p><p>155</p><p>156</p><p>157</p><p>158</p><p>159</p><p>160161</p><p>162</p><p>163164165</p><p>166167</p><p>168</p><p>169170</p><p>171172</p><p>173174175</p></li><li><p>Liberty Alliance Project Version 3.1SAML 2.0 Test Steps</p><p>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.</p><p>Note that while the and elements are not required in the SAML specifications or related schemas, these elements MUST be included in mes...</p></li></ul>

Recommended

View more >