1. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz “Standards are only the beginning.. …of the beginning.. … of interoperability” anon

2. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz NZ SAMS: An OASIS SAML v2.0 Case Study Colin Wallis State Services Commission New Zealand Government

3. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Context: Aotearoa

4. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Context: Specific Authentication-related Policy Strong emphasis on compliance with Privacy legislation No national identifier, no ID card, no exchange of biometrics No national security or illegal immigration drivers Inter-agency data matching prohibited except by (small number of) specific exceptions Citizen must control of use / release of data Opt-in: Citizens not compelled to use the services Opt-in: Government agencies not compelled to offer or use central or shared services Low risk, low budget approach

5. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Agenda What we’ve done Why write NZ SAMS? How was it done? What did we learn? Where to from here?

6. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz What we’ve done Constrained OASIS SAML v2.0 down to a smaller sub-set Includes conformance, metadata, bindings (HTTP Redirect, POST and Artifact) and Profiles (SSO, IdP Proxy and NameIdMapping) Published as “NZ SAMS” draft 0.9 for limited review and distributed to interested parties –OASIS SSTC –Liberty Alliance –Other similar govt programmes (US, Denmark, Ireland, Canada, etc.) –Product Vendors, Systems Integrators NZ SAMS part of a broader NZ Government “Authentication Standards” suite Authentication Standards part of a broader NZ Government e-GIF NZ Government e-GIF gradually becoming part of an NZ Government Enterprise Architecture Given agencies the desire and confidence to plan to implement NZ SAMS

7. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz http://www.e.govt.nz/standards/e-gif/authentication/nzsams/

8. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Agenda What we’ve done Why write NZ SAMS? How was it done? What did we learn? Where to from here?

9. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Why write NZ SAMS? 1/4 All the usual altruistic reasons –Interoperability –Make integration easier in future –Cost savings –Uniform user experience –etc.. …but really…

10. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Why write NZ SAMS? 2/4 Encouraging Certain Behaviours –Solution architecture –Product selection –Integration choices Goal: More agencies take up All-of Government Services –Reducing future barriers to uptake by influencing choices made today

11. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Why write NZ SAMS? 3/4 Agency education –learning a “best practice” approach Vendor preparation –Every government procurement requires compliance with NZ e-GIF standards Product selection –Government agencies will purchase NZ SAMS/SAML compliant products

12. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Why write NZ SAMS? 4/4 Alternative options (all discarded) –Do nothing - let vendors sort it out at implementation time –Write our own proprietary NZ Security Assertion Standard –Get someone else to constrain OASIS SAML 2.0 and enforce it from above –Write non enforceable guidelines

13. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Agenda What we’ve done Why write NZ SAMS? How was it done? What did we learn? Where to from here?

14. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz How Was it Done? Involve all the stakeholders 1/5 Government agency use cases are the foundation Participation and buy-in from all actors in identity management - users, government service agencies, vendors, standards organisations – everyone owns part of the outcome Support the privacy-respecting and user control/data release principles of NZ’s privacy legislation Get stakeholders focussed on the user experience, not focussed on each other

15. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz How was it done? Balancing risk vs. Reward 2/5 October 2004: “Security Assertion Messaging” - one of 5 standards to be published by June 2006 (Cabinet Paper) January 2005: Early planning assumed SAML 1x (1 st increments of the Government Logon Service use SAML 1x) March 2005: SAML V2.0 published, rapidly gains support May 2005: Decision time - SAML 1x or SAML V2? June 2005: SAML V2.0 Help! No deployment experience of SAML V2.0 Help! SME’s needed!

16. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz How was it done? The “KISS” Principle 3/5 Start with SAML V2.0 conformance specification and metadata to target “Liberty Interoperable” vendors Distil down Government agency use cases to a limited set of SAML v2.0 profiles, bindings, protocols Key Profile: SAML v2.0 Web Browser SSO profile Key Binding Bindings: HTTP Redirect, HTTP POST and HTTP Artifact, SOAP-over-HTTP Key Protocol: SAML v2.0 Authentication Request Supporting Profile: the SAML v2.0 Name Identifier Mapping Supporting Protocol: SAML v2.0 Assertion Query and Request

17. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz How was it done? Encourage early implementers 4/5 Education sector’s ESSA programme All of government Government Logon Service (GLS) All of government Identity Verification Service (IVS) Inland Revenue online transaction services SSC - Collaboration application Other agencies, including local govt bodies

18. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz How was it done? Experts write and teach Stakeholders listen and learn! 5/5 Working Group dynamics – agency reps submit use cases, Subject Matter Experts distill and question on conference line Subject Matter Expert #1: OASIS TC member US based to map use cases to SAML profiles Subject Matter Expert #2: Independent US based consultant to peer review Subject Matter Expert 1’s drafts “Soft” release draft as input to OASIS and Liberty Alliance for comment

19. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Agenda What we’ve done Why write NZ SAMS? How was it done? What did we learn? Where to from here?

20. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz What did we learn? Lessons & considerations 1/2 “Interoperable” standards always improving – Version 1.0 syndrome An open standard developed to improve interoperability is almost certain not to interoperate! Implementation experience and vendor software support lags behind standards Consider the IPR implications of the deliverable Consider the maintenance and extension cost of the deliverables Control scope creep Expert advice essential Join and participate in standards creation and implementation bodies – it’s a long term symbiotic relationship

21. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz What did we learn? What would we have done differently? 2/2 A longer orientation period on SAML for the working group – not just passive reading of material but “live” presentations from Subject Matter Experts More consideration of timing – not that we had much choice! Stronger links with the local vendor community during development Raise the profile of the work during development through effective PR and communication strategies Brought in our Subject Matter Experts “face to face” every 4-6 months

22. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Agenda What we’ve done Why write NZ SAMS? How was it done? What did we learn? Where to from here?

23. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Where to from here? Seek feedback, modify and release as V1.0 Implement NZ SAMS in prototype development of IVS and other implementations Monitor new developments and extensions: e.g. Simple Sign from OASIS SSTC, SAML token Profile in WS BSP from WS-I Monitor “Liberty Interoperable” vendor list Look to Web Services specifications to supplement browser use cases: e.g. Liberty ID-WSF 2.0 Ramp up engagement with standards organisations, other jurisdictions, vendors and the private sector Work towards upgrading NZ SAMS compliance rating in the NZ e-GIF – from “Under Development” to “Recommended”

24. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Colin Wallis colin.wallis@ssc.govt.nz http://www.e.govt.nz/standards/e-gif/authentication

25. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Appendix NZ SAMS graphics and content examples

26. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz NZ SAMS: Generic Usage pattern – SP initiated web browser SSO

27. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Messa ge BindingMessage ContentSAML Message (or message parts) Security Transport Channel Security 1HTTPService user makes requests for content not requiring authentication and the SP supplies non- sensitive content until sensitive content requested. Possibly cookie placed by the SP. –– 2HTTP–SSL/TLS 3HTTP RedirectSAML Message: The SP uses the SAML protocol. XML Signature MAY be used (if authentication of the SP is required by the IdP or if additional optional fields included) XML Encryption MAY be used (e.g. if the element used). SSL/TLS 4HTTPIdP presents logon page to service user’s browser.–SSL/TLS 5HTTPService user logs on to IdP using their authentication key(s). –SSL/TLS 6HTTP Artifact (carried in an HTTP Redirect) SAML Message: HTTP parameter carrying the dereference information (i.e. the SAML artifact) for the SAML protocol message below. No XML Signature No XML Encryption SSL/TLS 7SOAP/HTTP Artifact (Artifact from Artifact Resolution profile) SAML Message: SAML element. XML Signature or an alternative such as the GSN, secure VPN, or leased line) MUST be used. No XML Encryption Mutual SSLv3/ TLSv1 or GSN, secure VPN, leased line 8SOAP/HTTP Artifact (Artifact from Artifact Resolution profile) SAML Message: SAML element with the protocol message associated with the artifact; a SAML message in this case. The message contains the assertion. XML Signature No XML Encryption Mutual SSLv3/ TLSv1 or GSN, secure VPN, leased line

28. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz NZ SAMS: SP initiated web browser SSO variation – sector acts as IdP proxy for the user to manage identity attributes and authorisation in a single logon

29. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz NZ SAMS: Usage Pattern: authenticate at the GLS and fetch IVS attributes in a single logon: SP initiated with the Name ID Mapping profile

30. State Services Commission New Zealand Government Crown Copyright 2007 www.ssc.govt.nz Table 6 – NZ SAMS constraints on OASIS SAML v2.0 conformance requirements SectionLineWhat is excluded or altered from the SAML v2.0 Conformance Requirements Specification 3.2 Table 2 182 - 1 8 3 The following features are REQUIRED:  Web SSO,, HTTP Redirect Web SSO,, HTTP POST Web SSO,, HTTP Artifact Artifact Resolution, SOAP Single Logout, (IDP & SP-initiated), HTTP redirect Single Logout, (IDP & SP-initiated), SOAP. The following features are NOT RECOMMENDED:  Enhanced Client/Proxy SSO  PAOS  Name Identifier Management, (HTTP redirect and SOAP, both IDP and SP-initiated)*  Identity Provider Discovery (cookie). (Name Identifier Management is not in the initial release of this Standard because deleting or changing service users’ federated identifiers from the system, adding and deleting user federated identifiers/logon tags from a SAML entity (for example the GLS) will not be in control of the service user, will not be done with SAML, but will be done by some yet to be agreed out of band process probably based on current agency implementations.)