Suomi.fi e-identification Technical interface description

Similar documents
AAI Login Demo. SWITCHaai Introduction Course Bern, 1. March Daniel Lutz

Session 2.1: Federations: Foundation. Scott Koranda Support provided by the National Institute of Allergy and Infectious Diseases

Leave Policy. SAML Support for PPO

Implement SAML 2.0 SSO in WLS using IDM Federation Services

FAS SAML Integration Guide

Kaltura MediaSpace SAML Integration Guide. Version: 5.0

Security Assertion Markup Language (SAML) applied to AppGate XDP

Web Based Single Sign-On and Access Control

Introducing Shibboleth. Sebastian Rieger

Higgins SAML2 IdP Tutorial

Single Sign-On (SSO) Using SAML

Directories Services and Single Sign-On for Collaboration

Cyber Authentication Technology Solutions Interface Architecture and Specification Version 2.0: Deployment Profile

GFIPM Web Browser User-to-System Profile Version 1.2

i-ready Support for Single Sign-On (SSO)

Research Collaboration IAM Needs

Single Sign-On User Guide. Cvent, Inc 1765 Greensboro Station Place McLean, VA

Implementation profile for using OASIS DSS in Central Signing services

SAML 2.0 SSO Extension for Dynamically Choosing Attribute Values

Single Sign-On Implementation Guide

Identity Provider for SAP Single Sign-On and SAP Identity Management

Integration Guide. PingFederate SAML Integration Guide (SP-Initiated Workflow)

Media Shuttle SAML Configuration. October 2017 Revision 2.0

SERVICE DESCRIPTION. Population Register Centre s online services

Jagiellonian University Norm DTI/01-2

Oracle Utilities Opower Solution Extension Partner SSO

SAMLv2: HTTP POST NoXMLdsig Binding

SAML Authentication with Pulse Connect Secure and Pulse Secure Virtual Traffic Manager

Configure ISE 2.3 Guest Portal with OKTA SAML SSO

SAML V2.0 EAP GSS SSO Profile Version 1.0

eidas SAML Message Format

This section includes troubleshooting topics about single sign-on (SSO) issues.

ComponentSpace SAML v2.0 Developer Guide

SAML-Based SSO Solution

Single Logout with the SWITCH edu-id IdP

SAML Profile for Privacy-enhanced Federated Identity Management

Identity management. Tuomas Aura CSE-C3400 Information security. Aalto University, autumn 2014

Oracle Utilities Opower Energy Efficiency Web Portal - Classic Single Sign-On

Single Sign-On Implementation Guide

SAML 2.0 SSO. Set up SAML 2.0 SSO. SAML 2.0 Terminology. Prerequisites

Network Security. Chapter 10. XML and Web Services. Part II: II: Securing Web Services Part III: Identity Federation

SAML V2.0 Implementation Pro le for Federation Interoperability

ONE ID Provincial Identity Federation

SAML 2.0 Profile. Trusted Digital Identity Framework August 2018, version 1.0

ISA 767, Secure Electronic Commerce Xinwen Zhang, George Mason University

Identity management. Tuomas Aura T Information security technology. Aalto University, autumn 2011

Building a Well Managed Cloud Application. Okta Inc. 301 Brannan Street San Francisco, CA

Integrating the YuJa Enterprise Video Platform with Dell Cloud Access Manager (SAML)

E-services instructions The City of Helsinki e-services support, open Mon-Fri from 8 AM to 6 PM Tel.

ComponentSpace SAML v2.0 Configuration Guide

Lesson 13 Securing Web Services (WS-Security, SAML)

Integration of the platform. Technical specifications

SAML V2.0 Basics. Eve Maler Sun Microsystems, Inc.

Security Provider Integration SAML Single Sign-On

How to Configure Authentication and Access Control (AAA)

Introduction to application management

Security Provider Integration: SAML Single Sign-On

Security Analysis of eidas The Cross-Country Authentication Scheme in Europe

Morningstar ByAllAccounts SAML Connectivity Guide

Test Plan for Liberty Alliance SAML Test Event Test Criteria SAML 2.0

Single Sign-On with Sage People and Microsoft Active Directory Federation Services 2.0

ComponentSpace SAML v2.0 Configuration Guide

Public Key Infrastructure PKI. National Digital Certification Center Information Technology Authority Sultanate of Oman

Integrating VMware Workspace ONE with Okta. VMware Workspace ONE

Generic Structure of the Treatment Relationship Assertion

RECOMMENDED DEPLOYMENT PRACTICES. The F5 and Okta Solution for High Security SSO

SAML-Based SSO Solution

CA SiteMinder. Federation in Your Enterprise 12.51

Access Manager Applications Configuration Guide. October 2016

Security Provider Integration SAML Single Sign-On

AdminCamp Christian Henseler, Christian Henseler,

National architecture for digital services in Finland, Suomi.fi Services

Integration of Agilent UV-Visible ChemStation with OpenLAB ECM

TECHNICAL GUIDE SSO SAML Azure AD

Nordea e-identification Service description

Test Plan for Kantara Initiative Test Event Test Criteria SAML 2.0

Configuring Single Sign-on from the VMware Identity Manager Service to Marketo

All about SAML End-to-end Tableau and OKTA integration

Enterprise Adoption Best Practices

eidas-node Error Codes

SAML V2.0 Deployment Profiles for X.509 Subjects

SELF SERVICE INTERFACE CODE OF CONNECTION

Access Manager 3.2 Service Pack 2 IR1 resolves several previous issues.

Cloud Access Manager Configuration Guide

System Administrator s Guide Login. Updated: May 2018 Version: 2.4

Welcome to Oracle Service Cloud Ask the Experts

Integration Guide. SafeNet Authentication Manager. Using SAM as an Identity Provider for PingFederate

DocuSign Spring '16 Release Notes

Webthority can provide single sign-on to web applications using one of the following authentication methods:

Application Note. Web Signing. Document version

Single Sign On for Google Apps with NetScaler Unified Gateway

Integrating YuJa Active Learning into Google Apps via SAML

eidas Technical Specifications

ADFS Setup (SAML Authentication)

How to Configure Fiori Launchpad and Web Dispatcher to Support SAML2 Using SAP Identity Provider Step-by-Step

NAB TRANSACT. Direct Post v2.1.2 Integration Guide

NemID JS Developer Support site. Guidelines

Abusing Windows Opener to Bypass CSRF Protection (Never Relay On Client Side)

Regions OnePass USER GUIDE. It s time to expect more. Regions Bank Member FDIC Revised

BI Office. Web Authentication Model Guide Version 6

Transcription:

Suomi.fi e-identification Technical interface description 1 Suomi.fi e-identification operating environment Suomi.fi e-identification offers a user authentication service for e-services across a SAML 2.0 compliant interface. For end users, Suomi.fi e-identification offers a choice of their preferred method of identification and single sign-on to e-services connected to Suomi.fi e-identification. The e-service may limit the set of users tokens that are accepted in the identification. If a user has been identified with a strong authentication method, Suomi.fi e-identification will complement the user s data with Population Information System data. The Figure below describes the operating environment of Suomi.fi e-identification. Figure 1: Suomi.fi e-identification operating environment 1.1 General description of how Suomi.fi e-identification operates An e-service uses Suomi.fi e-identification to authenticate a user. Suomi.fi e-identification displays to the users a list of token providers accepted by the e-service, of which the users can select their preferred one for the identification process. 1

Suomi.fi e-identification contacts the Population Information System to check that the personal identity code of an identified user is active and that its owner is alive, and complements the user s data with Population Information System data. If successful, Suomi.fi e-identification produces a SAML 2.0 compliant message, in which the required data is communicated to the e-service via the user s browser. In Suomi.fi e-identification architecture, direct links are not needed between the e-service, Suomi.fi e-identification and token provider services, as all traffic is communicated via the user s browser in compliance with the SAML 2.0 standard. The connection used for the identification process and the personal data transmitted during it are encrypted using a HTTPS protocol, and the parties identifies and message integrity are ascertained in compliance with the SAML 2.0 standard. 1.2. Single sign-on and single logout Suomi.fi e-identification creates a single sign-on (SSO) session for an authenticated end user, which gives the user access to all e-services connected to Suomi.fi e-identification with a single login. A single sign-on session is valid for 32 minutes. An e-service is informed of the remaining duration of the session in connection with the login, and it has to initiate a re-login when the session times out. An e-service connected to Suomi.fi e-identification must support SAML 2.0 compliant single logout (SLO). As the user logs out, other sessions associated with the same single sign-on session are also terminated. The e-service must be capable of both initiating the logout process and processing logout requests received from Suomi.fi e-identification. 1.3 Operating environment requirements for a Suomi.fi e-identification end user Suomi.fi e-identification is intended for browser-based use. Its user interfaces, as well as the interfaces specific to the token providers services used in Suomi.fi e-identification, are browser based. Different language options are available in Suomi.fi e-identification (Finnish, Swedish or English). Users do not need to install any software on their workstations to use Suomi.fi e-identification. The tokens used to identify a user may require additional components, including certificate card readers. 1.3.1 User s browser software Browser requirements set by Suomi.fi e-identification: Suomi.fi e-identification is HTML 5.0 compliant but also works with a more basic layout if the browser does not support HTML 5.0. In order to use the service, HTTP session cookies and JavaScript need to be enabled in the browser. The service uses TLS version 1.2 (versions 1.0. and 1.1 are supported to ensure compatibility between different environments). At minimum, 128-bit encryption is used. 2

1.3.2 Use of tokens A user may be required to have specific equipment or software to use tokens: Banking IDs may, for example, be based on a list of key figures or a mobile application. For identification with a certificate card issued by the Population Register Centre (e.g. an electronic ID card, a health care smart card, a civil service card), a card reader and card software installed on the workstation are required. In identification based on a mobile certificate, the operator s SIM card and a mobile phone are used. 1.3.3 Suomi.fi e-identification on a mobile device The user interface of Suomi.fi e-identification runs in a browser. It is also available on mobile terminal devices, however with the browser restrictions described in section 1.2.1. Different tokens may set restrictions on mobile device use. 2 General technical properties of Suomi.fi e-identification A SAML 2.0 interface is used for Suomi.fi e-identification. The messages are transmitted in a UTF- 8 format. 2.1 Technical connection An e-service connects to Suomi.fi e-identification by submitting its metadata to Suomi.fi e- Identification maintenance. For a description of the metadata file content, see the document E- service metadata. Suomi.fi e-identification and the e-service must sign the SAML 2.0 messages sent by them. To authenticate these messages, the recipient must have the sender s public key (contained in a certificate). The certificate of Suomi.fi e-identification is downloaded to the e-service s server when the e-service is connected to the identification service. The e-service transmits its certificate to Suomi.fi e-identification as part of its metadata. 2.2 SAML message exchanges SAML messages between Suomi.fi e-identification and an e-service are communicated through the user's browser using the HTTP commands GET, REDIRECT and POST. The SAML 2.0 standard uses HTTP command bindings to define how each HTTP command transmits a SAML message. The e-service calls Suomi.fi e-identification by sending an identification request message that includes a return address using the GET or POST command in the user s browser. Suomi.fi e-identification allows users to identify themselves with the method of their choice. Suomi.fi e-identification sends a return message to the e-service with a POST command to the return address. The connections are encrypted using TLS protocol; in other words, all call and response messages are sent using HTTPS connections. The e-service must ensure that all connections between the user's browser and the e-service are HTTPS-protected. 3

Suomi.fi e-identification is called using a HTTPS connection. The return address contained in the message of the e-service must use the HTTPS protocol. All SAML messages are signed to authenticate the sender and to ensure the integrity and immutability of the messages. The parties must check the signatures of the messages they receive. 2.3 Testing Connecting an e-service to Suomi.fi e-identification is easier if one has a tool that decodes SAML messages. Extension packs for this purpose are available for browsers, including the SAML tracer for Firefox and SAML Chrome Panel and SAML Message Decoder for Chrome. 3 Identification Once Suomi.fi e-identification has authenticated a user, a single sign-on session to all e-services connected to Suomi.fi e-identification is created for him or her. While token provider may also offer single sign-on functionality, Suomi.fi e-identification is unable to use it. 4

3.1 An example of an identification transaction Figure 2. An example of an identification transaction. 1. The user activates the login 2. The e-service detects that the user has not been identified 3. The e-service directs the user to Suomi.fi e-identification and simultaneously sends a SAML identification request to the browser 4. The user s browser communicates the SAML identification request to Suomi.fi e- Identification. 5. Suomi.fi e-identification receives the SAML identification request and returns the token selection page to the browser. 6. The user selects his or her preferred token and identifies himself or herself. 7. The token provider redirects the browser to Suomi.fi e-identification. 8. The browser transmits to Suomi.fi e-identification the user s unique identifier received from the token provider. 9. Suomi.fi e-identification creates a single sign-on session and a SAML message that contains the user s data, which it sends to the browser while directing the browser to the e-service. 5

10. The browser sends the personal data contained in the SAML identification response to the e- service, which initiates a session for an identified user. 11. The e-service returns to the user the protected resource he or she requested originally. For example, the e-service may send the identification request by submitting to the browser a HTML form which contains the SAML message in hidden fields. The form may be sent by a script that is executed automatically, or by the user who clicks on the Submit button on the form.... <form name= APRO method= POST action= https://testi.apro.tunnistus.fi/idp/profile/saml2/post/sso"> <input type= hidden name= SAMLRequest value= fzjbu8i... /> <input type= hidden name= RelayState value= ss%3amem%3ac3 /> <input type= hidden name= SigAlg value =http%3a%2f%2fwww.w3.org%2f2001%2f04%2fxmldsig-more%23rsa-sha256 /> <input type= hidden name= Signature value= so%2fw.. /> </form>... var form = document.apro; form.submit();... <input type="submit" value="siirry tunnistautumaan"> The examples below use the following name specifications that have been included in full SAML 2.0 messages when transmitting them: xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion" xmlns:saml2p="urn:oasis:names:tc:saml:2.0:protocol" 3.2 Identification request The data that directs the identification transaction is defined in the metadata submitted by the e- service when connecting to Suomi.fi e-identification. In an identification request, the e-service may change the actions defined in the metadata. For example, the language that Suomi.fi e-identification should use in its user interface, or the tokens that the user may select for login, may be selected in the identification request. The supported bindings are HTTP POST and HTTP REDIRECT. E-service ID Explanation E-service ID. Refers to the EntityID attribute specified in the e-service metadata. Based on this ID, Suomi.fi e-identification service can find the e-service specifications, including the certificate that allows it to authenticate the origin of the message. Location saml2:issuer element in saml2p:authnrequest element Format String, maximum length 1024 characters. URL format 6

<saml2p:authnrequest > <saml2:issuer>https://kalastus.kunta.fi/lupa-asiat</saml2:issuer> Suomi.fi e-identification address Explanation Target address of the message, or the address of Suomi.fi e-identification. Specified in Suomi.fi e-identification metadata for each binding. Location Destination attribute of element saml2p:authnrequest Format: String <saml2p:authnrequest Destination= Time stamp Explanation Identification request generation time. Location issueinstant attribute of the sam12p:authnrequest element Format: String, 20 characters. DateTime data type of W3C XML Schema specification in format: YYYY-MM- DDThh:mm:ss in UTC format without time zone. <saml2p:authnrequest IssueInstant= 2015-09-28T16:27:36Z > User interface language Explanation User interface language Location LG element of the vetuma xmlns="urn:vetuma:saml:2.0:extensions element of the saml2p:extensions element Format: String, 2 characters. ISO 639-1 standard language code. The languages supported in Suomi.fi e-identification are Finnish (fi), Swedish (sv) and English (en). The language code can also be transmitted in the HTTP protocol as the value of the variable locale (similarly to the Transaction ID transmitted in the variable RelayState). This method should only be used if, for technical reasons, the language code cannot be included in the SAML message. Mandatory No <saml2p:authnrequest 7

<saml2p:extensions> <vetuma xmlns="urn:vetuma:saml:2.0:extensions"> <LG>sv</LG> </vetuma> </saml2p:extensions> E-service return address or reference to return address Explanation Return address or reference to return address to which the identification response is transmitted. Location AssertionConsumerServiceURL or AssertionConsumerServiceIndexattribute of the saml2p:authnrequest element. AssertionConsumerServiceURL attribute value must be equal to the return address specified in the e-service metadata. Alternatively, reference can be made to the return address specified in the e-service metadata using the AssertionConsumerServiceIndex attribute. Format: A URL having https protocol, or Suomi.fi e-identification will reject the message (error code Requester). Mandatory No <saml2p:authnrequest AssertionConsumerServiceURL= https://kalastus.kunta.fi/saml2/post" or <saml2p:authnrequest AssertionConsumerServiceIndex= 1 Transaction ID Explanation A transaction ID specified by the e-service that makes it possible to preserve the e- service status information throughout the identification transaction. Based on the ID issued by it, the e-service can, for example, direct the user to the correct page after identification. Rather than being included in the SAML message, the transaction ID is sent with the HTTP protocol. Location RelayState variable. Format Max 80 bytes Mandatory No <form method="post" action=. <input type="hidden" name="relaystate" value="token" /> 8

Accepted tokens Explanation When making the identification request, the e-service may restrict the set of tokens specified in its basic data by listing the tokens that are accepted in the identification request. If the tokens have not been listed, all tokens specified in the e-service basic data are accepted. Location saml2:authncontextclassref element within the saml2p:requestedauthncontext element Format: String with the possible values of: urn:oid:1.2.246.517.3002.110.1 = online banking ID urn:oid:1.2.246.517.3002.110.2 = certificate card urn:oid:1.2.246.517.3002.110.3 = mobile certificate urn:oid:1.2.246.517.3002.110.5 = KatsoOTP (one-time password) urn:oid:1.2.246.517.3002.110.6 = KatsoPWD (password) In a customer testing environment also: urn:oid:1.2.246.517.3002.110.999 = test token only used in testing environments Mandatory Not mandatory. If no tokens have been specified, the tokens listed in the e-service basic data are shown. <saml2p:authnrequest <saml2p:requestedauthncontext xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion" Comparison="exact"> <saml2:authncontextclassref> urn:oid:1.2.246.517.3002.110.1 </saml2:authncontextclassref> </saml2p:requestedauthncontext> Explanation Location Format: Token processing saml2p:nameidpolicy element within the saml2p:authnrequest element Attributes AllowCreate and Format. Used in: AllowCreate="true" and Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient". <saml2p:authnrequest <saml2p:nameidpolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameidformat:transient"/> 9

3.3 Identification response In the identification response, Suomi.fi e-identification returns the data of an identified user and the used token. In addition to the user's identify the e-service may, for example, receive the user s name data and up-to-date address data from the Population Information System. The supported binding is HTTP POST. This section discusses data related to the session and the identification transaction. For the data transmitted on the user, see the page attributes transmitted on an identified user. Time stamp Explanation Identification response generation time. Location IssueInstant attribute of the saml2p:response element Format: String, 20 characters. DateTime data type of W3C XML Schema specification in format: YYYY-MM- DDThh:mm:ss in UTC format without time zone. <saml2p:response IssueInstant= 2015-09-28T16:27:36Z Transaction ID Explanation A transaction ID sent by the e-service in the identification call that makes it possible to preserve the e-service status information throughout the identification transaction. Based on the ID issued by it, the e-service can, for example, direct the user to the correct page after identification. Rather than being included in the SAML message, the transaction ID is transmitted as a HTTP command parameter. Location RelayState parameter Format Max 80 bytes Mandatory No <form method="post" action=. <input type="hidden" name="relaystate" value="token" /> Session ID Explanation A single sign-on session ID created by Suomi.fi e-identification. The saml2:nameid element contains the attributes NameQualifier (Suomi.fi e- Identification ID) and SPNameQualifier (e-service ID) as well as Format (ID format 10

definition), which must be included unaltered in the logout request in addition to the ID. Location saml2:nameid element Format String, maximum length 1,024 characters. <saml2p:response <saml2:assertion <saml2:subject> <saml2:nameid Format="urn:oasis:names:tc:SAML:2.0:nameidformat:transient" NameQualifier="https://testi.apro.tunnistus.fi/idp1" SPNameQualifier="https://kalastus.kunta.fi/lupa-asiat"> AAd... dsua== </saml2:nameid> Explanation Location Format Mandatory Level of authentication The token selected by the user. saml2:authncontextclassref element of the saml2:authncontext element of the saml2:authnstatement element An identifier in the format URN:OID is returned as the value. urn:oid:1.2.246.517.3002.110.1 online banks urn:oid:1.2.246.517.3002.110.2 certificate card urn:oid:1.2.246.517.3002.110.3 mobile certificate urn:oid:1.2.246.517.3002.110.5 KatsoOTP urn:oid:1.2.246.517.3002.110.6 KatsoPWD test token only used in the customer testing urn:oid:1.2.246.517.3002.110.999 environment Yes <saml2p:response <saml2:assertion <saml2:authnstatement <saml2:authncontext> <saml2:authncontextclassref> urn:oid:1.2.246.517.3002.110.1 </saml2:authncontextclassref> Return status An indication of whether or not the identification transaction was successful is Explanation communicated to the e-service. Location sampl2p:status element of the sam12p:response element. Format String. See status codes and explanations below. Higher level status codes Success= Identification was successful 11

Requester = Error in identification request Responder = Processing of identification request failed VersionMismatch = Incorrect version in the identification request Complementary status codes: AuthnFailed = Identification failed RequestDenied = Identification rejected by the token The status element may include a StatusMessage element that contains more detailed information on the error. <saml2p:response <saml2p:status> <saml2p:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </saml2p:status> 4 Logout The figure below lists the SAML messages exchanged between e-services and Suomi.fi e- Identification when a user has been logged in to e-services connected to Suomi.fi e-identification. Figure 3. SAML messages exchanged by e-services and Suomi.fi e-identification in the logout process. The messages are transmitted via the user s browser. 12

4.1 Logout request An e-service can send a logout request to Suomi.fi e-identification or vice versa (see Figure 3). The structure of the message is similar in both situations. The e-service must terminate the local browser session before sending a logout request to Suomi.fi e-identification. The supported bindings are HTTP POST and HTTP REDIRECT. E-service ID Explanation E-service ID. Refers to the EntityID attribute specified in the e-service metadata. Based on this ID, Suomi.fi e-identification can find the e-service definitions, including the certificate that allows it to verify the origin of the message. Location saml2:issuer element of the saml2p:logoutrequest element Format String, maximum length 1,024 characters. URL format <saml2p:logoutrequest <saml2:issuer>https://kalastus.kunta.fi/lupa-asiat </saml2:issuer> Time stamp Explanation Logout request creation time. Location IssueInstant attribute of the saml2p:logoutrequest element String, 20 characters. Format: DateTime data type of W3C XML Schema specification in format: YYYY-MM- DDThh:mm:ss in UTC format without time zone. <saml2p:logoutrequest IssueInstant= 2015-09-28T16:27:36Z > Session ID Explanation A single sign-on session ID created by Suomi.fi e-identification that the e-service received in the identification response. Location Format In addition to the ID value, the saml2:nameid element must contain unaltered the attributes included in the identification response (NameQualifier, SPNameQualifier and Format). saml2:nameid element String <saml2p:logoutrequest <saml2:nameid xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" 13

NameQualifier="https://testi.apro.tunnistus.fi/idp1" SPNameQualifier="https://kalastus.kunta.fi/lupa-asiat"> AAd... dsua== </saml2:nameid> User interface language Explanation The e-service may specify the language in which the interfaces are displayed. Location LG element of the vetuma xmlns="urn:vetuma:saml:2.0:extensions element of the saml2p:extensions element Format: String, 2 characters. Language code compliant with the ISO 639-1 standard. The languages are Finnish (fi), Swedish (sv) and English (en). Mandatory No <saml2p:logoutrequest <saml2p:extensions> <vetuma xmlns="urn:vetuma:saml:2.0:extensions"> <LG>sv</LG> </vetuma> </saml2p:extensions> Transaction ID Explanation A transaction ID issued by the e-service that makes it possible to preserve the e- service status information throughout the logout transaction. For example, it can be used by the e-service to direct the user to a page specified by it after logout. Rather than being included in the SAML message, the transaction ID is sent in the HTTP protocol. Location RelayState parameter Format Max 80 bytes Mandatory No <form method="post" action=. <input type="hidden" name="relaystate" value="token" /> 4.2 Logout response An e-service can send a logout response to Suomi.fi e-identification or vice versa (see Figure 3). The structure of the logout response is similar in both situations. The supported bindings are HTTP POST and HTTP REDIRECT. Time stamp Explanation Logout response creation time. Location IssueInstant attribute of the saml2p:logoutresponse element Format: String, 20 characters. 14

DateTime data type of W3C XML Schema specification in format: YYYY-MM- DDThh:mm:ss in UTC format without time zone. <saml2p:logoutresponse IssueInstant= 2015-09-28T16:27:36Z E-service ID Explanation E-service ID. Refers to the EntityID attribute specified in the e-service metadata. Location saml2:issuer element in saml2p:logoutresponse element String, maximum length 1,024 characters. Format URL format <saml2p:logoutresponse <saml2:issuer>https://kalastus.kunta.fi/lupa-asiat </saml2:issuer> Transaction ID Explanation A transaction ID issued by the e-service that makes it possible to preserve the e- service status information throughout the logout transaction. For example, it can be used by the e-service to direct the user to a page specified by it after logout. Rather than being included in the SAML message, the transaction ID is transmitted as a HTTP command parameter. Location RelayState parameter Format Max 80 bytes Mandatory No <form method="post" action=. <input type="hidden" name="relaystate" value="token" /> Return status Explanation An indication of whether or not the logout was successful is communicated to the e- service. Location sampl2p:status element of the sam12p:logoutresponse element. Format String. See status codes and explanations below. Higher level status codes Success = Logout succeeded Requester = Error in logout request Responder = Processing of logout request failed VersionMismatch = Incorrect version in the logout request Complementary status codes: AuthnFailed = Logout failed 15

RequestDenied = Logout request rejected by the service The status element may include a StatusMessage element that contains more detailed information on the error. <saml2p:logoutresponse <saml2p:status> <saml2p:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </saml2p:status> 16