Standards are only the beginning of the beginning

NZ SAMS: An OASIS SAML v 2. 0 Case Study Colin Wallis State Services

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

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 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

What we’ve done • Constrained OASIS SAML v 2. 0 down to a smaller sub-set • Includes conformance, metadata, bindings (HTTP Redirect, POST and Artifact) and Profiles (SSO, Id. P Proxy and Name. Id. Mapping) • 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 State Services Commission New Zealand Government Crown Copyright 2007 www. ssc. govt. nz

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

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… 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 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 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 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 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 1 x (1 st increments of the Government Logon Service use SAML 1 x) • March 2005: SAML V 2. 0 published, rapidly gains support • May 2005: Decision time - SAML 1 x or SAML V 2? • June 2005: SAML V 2. 0 • Help! No deployment experience of SAML V 2. 0 • Help! SME’s needed! 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 V 2. 0 conformance specification and metadata to target “Liberty Interoperable” vendors • Distil down Government agency use cases to a limited set of SAML v 2. 0 profiles, bindings, protocols • Key Profile: SAML v 2. 0 Web Browser SSO profile • Key Bindings: HTTP Redirect, HTTP POST and HTTP Artifact, SOAP-over-HTTP • Key Protocol: SAML v 2. 0 Authentication Request • Supporting Profile: the SAML v 2. 0 Name Identifier Mapping • Supporting Protocol: SAML v 2. 0 Assertion Query and Request 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 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 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 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 State Services Commission New Zealand Government Crown Copyright 2007 www. ssc. govt. nz

Where to from here? • Seek feedback, modify and release as V 1. 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” State Services Commission New Zealand Government Crown Copyright 2007 www. ssc. govt. nz

http: //www. e. govt. nz/standards/e-gif/authentication Colin Wallis colin. wallis@ssc. govt. nz State Services Commission

Appendix NZ SAMS graphics and content examples State Services Commission New Zealand Government Crown

NZ SAMS: Generic Usage pattern – SP initiated web browser SSO State Services Commission

Messa ge Binding Message Content SAML Message (or message parts) Security Transport Channel Security 1 HTTP – – 2 HTTP Service user makes requests for content not requiring authentication and the SP supplies nonsensitive content until sensitive content requested. Possibly cookie placed by the SP. – SSL/TLS 3 HTTP Redirect SAML Message: The SP uses the SAML <Authn. Request> protocol. XML Signature MAY be used (if authentication of the SP is required by the Id. P or if additional optional fields included) XML Encryption MAY be used (e. g. if the <Name. ID> element used). SSL/TLS 4 HTTP Id. P presents logon page to service user’s browser. – SSL/TLS 5 HTTP Service user logs on to Id. P using their authentication key(s). – SSL/TLS 6 HTTP 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 7 SOAP/HTTP Artifact (Artifact from Artifact Resolution profile) SAML Message: SAML <Artifact. Resolve> element. XML Signature or an alternative such as the GSN, secure VPN, or leased line) MUST be used. No XML Encryption Mutual SSLv 3/ TLSv 1 or GSN, secure VPN, leased line 8 SOAP/HTTP Artifact (Artifact from Artifact Resolution profile) SAML Message: SAML <Artifact. Response> element with the protocol message associated with the artifact; a SAML <Response> message in this case. The <Response> message contains the assertion. XML Signature No XML Encryption Mutual SSLv 3/ TLSv 1 or GSN, secure VPN, leased line State Services Commission New Zealand Government Crown Copyright 2007 www. ssc. govt. nz

NZ SAMS: SP initiated web browser SSO variation – sector acts as Id. P proxy for the user to manage identity attributes and authorisation in a single logon 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 State Services Commission New Zealand Government Crown Copyright 2007 www. ssc. govt. nz

Table 6 – NZ SAMS constraints on OASIS SAML v 2. 0 conformance requirements Section Line What is excluded or altered from the SAML v 2. 0 Conformance Requirements Specification 3. 2 Table 2 182 The following features are REQUIRED: 18 3 Web SSO, <Authn. Request>, HTTP Redirect Web SSO, <Response>, HTTP POST Web SSO, <Response>, HTTP 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) Services will not be in control of the service user, will not State be done with. Commission Zealand SAML, but will be done by some yet to be agreed New out of band. Government Crown Copyright 2007 process probably based on current agency implementations. ) www. ssc. govt. nz