IAM Application Integration Guide

Transcription

1 IAM Application Integration Guide Date 03/02/2015 Version 0.1

2 DOCUMENT INFORMATIE Document Title IAM Application Integration Guide File Name IAM_Application_Integration_Guide_v0.1_SBO.docx Subject Document Status Draft Version 0.1 Release Date Version Author Stefan Bocken Document Owner Wouter Vandenbussche Reviewers Approvers DOCUMENT GESCHIEDENIS Version Date Status Changed By Remarks /11/2014 Draft Stefan Bocken Initial version /12/2014 Draft Wouter Vandenbussche Review /01/2014 Draft Stefan Bocken /01/2015 Wouter Vandenbussche Review /01/2015 Stefan Bocken /02/2015 Stefan Bocken DOCUMENT GOEDKEURING Approver(s) name(s) Date GERELATEERDE DOCUMENTEN Version Date Type Title 2

3 INHOUDSTAFEL 1 Business Role of Fedict IAM Procedures Onboarding Process Certificate Request Process Information Functional SAML Flow Information Categories Contexts Architecture Components according to the Reference Architecture FAS Integration from Architecture Perspective Technical Introduction to SAML Exchanged Attributes Syntax details Request and Response Examples

4 1 BUSINESS 1.1 Role of Fedict IAM The role of Fedict IAM within the egov framework situates itself in two domains. The first domain is strategic which incorporates making correct agreements regarding the services and interfaces but also on the used information models (identities, roles, mandates ). The second domain is tactical / operational. This relates to the actual employment of these agreements. Fedict IAM accommodates four strategic goals in regards to egovernment: Present transparent access to applications and information of the (federal) Belgian Government, taking into account the heterogeneous and distributed nature. Control and reduce the risks of unlawful access to these applications and guard the integrity. Increase the efficiency of the daily management of identities and roles Establish a technical architecture that guarantees the optimum operation and interoperability of the global system taking into account the autonomy of the different parties on a technical and operational level. Fedict delivers the operation and support for a common strategy on federal IAM by Governance on strategy IAM Framework Governance on tactics IAM Enterprise Architecture Governance on operations IAM Service (Level) Management, Security The Fedict IAM Program delivers Trusted Third Party advice regarding IAM on a strategic, tactical and operational level to other government departments or enterprises with a public function. This document focusses on the support for federal government departments in the implementation and connection of their systems with Fedict IAM. The government departments are Relying Parties who rely on Fedict IAM as Trusted Third Party and as such form a Circle of Trust. One of the most important ways of connecting to Fedict IAM is the Federal Authentication Service (FAS), My egov Login. Relying Parties can use this service to identify and authenticate their users. The service can also provide relevant attributes and roles to enable the Relying Party to make an authorization decision. 4

5 2 PROCEDURES 2.1 Onboarding Process Preparation The customer will, together with Fedict, prepare the onboarding specification. The necessary contracts are put in place to describe the trust relationship between the customer and Fedict Specification The specifications of the Relying Party will be documented in an onboarding document. This document describes the technical details of the trust between FAS and Relying Party and contains the metadata of the Relying Party, the desired attributes, role information, etc. This document is the base of trust between FAS and the Relying Party Configuration The configuration of the FAS is executed after completing the onboarding document. The FAS and all necessary components are configured to support the trust relation between FAS and the Relying Party. The configuration is first executed in the Fedict Integration environment (INT). After successful testing the configuration can be migrated to the production environment (PROD). 2.2 Certificate Request Process When using SAML it is common to sign SAML messages. This implicates for a Relying Party the creation of a signing key with accompanying certificate. This certificate can be signed by Fedict. After the creation of the signing key, the Relying Party needs to create a Certificate Signing Request (CSR) and send this to the Fedict Service Desk. Fedict will, as a Registration Authority (RA), deliver the new certificate signed by an approved Certificate Authority (CA). More information can be found here: rtificaten.jsp 5

6 3 INFORMATION The parties within a Circle of Trust interchange information to enable Identity Federation. This chapter offers a summary of the different types of information that is shared and how Fedict IAM treats this information. The first section of this chapter will give a functional overview of the SAML specification and illustrates how the communication works between the parties within a Circle of Trust. The second section offers an overview of the different categories of information and how they are used within Fedict IAM. 3.1 Functional SAML Flow The SAML specification defines three roles: the principal (the end-user), the identity provider (IdP FAS) and the Service Provider (SP Relying Party). The typical use case addressed by SAML, the principal requests a service from the Service Provider. The Service Provider requests and obtains an identity assertion from the Identity Provider. On the basis of this assertion, the Service Provider can make an access control decision in other words it can decide whether to perform some service for the connected principal. Before delivering the identity assertion to the Service Provider, the Identity Provider may validate the provided credentials of the principal such as eid certificate in order to authenticate the principal. SAML specifies the assertions between the three parties. The specification describes Requests and Responses. When a Service Provider requests an identity assertion it sends a SAML Authentication Request to the Identity Provider. After successful authentication the Identity Provider provides an 6

7 assertion through a SAML Authentication Response. This construction of Request and Response messages is also used for Single Log Out. Once a principal has authenticated to an Identity Provider, the Identity Provider may establish a session with the principal. The Identity Provider may subsequently issue assertions to Service Providers or other Relying Parties, based on this authentication event; a Relying Party may use this to establish its own session with the principal. In such a situation; the Identity Provider acts as a Session Authority and the Relying Parties as Session Participants. At some later time, the principal may wish to terminate his or her session. This use case can be satisfied using the Single Logout Profile. The principal may choose to terminate this global session by contacting an individual Session Participant (Relying Party). 3.2 Information Categories The customer of Fedict as a Relying Party trusts the information coming from Fedict IAM regarding identities and sessions. The shared information is divided in the following categories: Personal Information: defines the unique identity of the principal. E.g. Given name, last name, national registry number and personal contact details, etc. Privilege Information: describes the role information with their parameters assigned to the principal. Metadata Information: describes the properties of the session, SAML messages, etc. Metadata Information is exchanged with requests and responses. Privilege Information is only exchanged in a response by Fedict to the Relying Party. Personal information will be exchanged in a response by Fedict to the Relying Party. This information can also be used in an Attribute Query. This is used to obtain more information regarding the principal. For certain information it is necessary that the principal is registered in Fedict IAM or that an external source is contacted for information. 3.3 Contexts A user can authenticate within different contexts: Citizen Enterprise Once authenticated within a certain context the session exists only for that context. This means that Single Sign-on will only work within this context. More precise, when logged in as a citizen, Single Signon will work as long as the user is acting as a citizen. If the user wants to log on to an application in the context Enterprise, he will need to re-authenticate within the context Enterprise. 7

8 4 ARCHITECTURE A clear and consistent conceptual framework is needed to describe the different components in the Federation scenario between the Service Provider and the Federal Authentication Service, this to use a common terminology. Fairly easy to use concepts like Policy Enforcement Points, Policy Decision Points, Policy Administration Points, and Policy Information Points are commonly used and all parties need to be aware that these concepts can have a different meaning for different parties. Therefore it is necessary that the concerned parties are aware that a comprehensive IAM Enterprise Architecture is needed and that the interoperable interfaces are agreed. 4.1 Components according to the Reference Architecture Access Control Policy Enforcement Point The Policy Enforcement Point (PEP) is a component of the Service Provider that controls the access to the application. The PEP is active in two places in the architecture. On the one hand it will make sure that coarse-grained access control is implemented before the principal accesses the application. On the other hand it will implement a fine-grained access control based on business logic when the principal is using the application Conceptually the PEP will not make any decisions regarding a request to access the application. The PEP will transfer this request to the Policy Decision Point (PDP). Often the PEP and PDP are combined in one application although they still remain present in the architecture Access Control Policy Decision Point The policy Decision Point (PDP) is a component that decides whether or not the functionality will be made available based on the information of the principal (privilege information, personal information, etc). This component can be a part of the business logic layer or made available centrally. By viewing the PDP as a separate logic component it is possible to pass-through authorisation questions to f.e. a central authorisation server who answers these questions centrally for different applications and thus uniform across the organisation. The PDP bases these decisions on information of the principal obtained from the Policy Information Point. When the PEP forms an access question, the PDP will asks the necessary information from the PIP Access Control Policy Information Point The Policy Information Point (PIP) is a component of the PDP that delivers the principal information to the PDP. 8

9 The Service Provider acts as a PIP and provides session and privilege information received from the Identity Provider (FAS) Federation Service Provider A Federation Service Provider (SP) is a component in a Federation context who offers a service to the principal and trusts the principal information received from Trusted Third Parties. The SP requests this information with an authentication request to the FAS Identity Provider in a Federation Context Federation Identity Provider The Federation Identity Provider delivers information regarding identities to parties who rely on the answer of the IdP. This creates a Circle of Trust with the Relying Parties. The information can be of the following nature: Personal Information allows for the identification of the principal (e.g. national registry number) Contact Information contains all contact information like addresses or preferred language. Privilege Information contains all information regarding roles of the principal. The Identity Provider receives a request from the Relying Party but may first determine the identity of the principal. This identification will be concluded by an Access Control Identity Verification Point Access Control Identity Verification Provider The Access Control Identity Verification Provider (IVP) has as purpose to determine the identity of a principal. The FAS uses the login screens of Fedict, where the principal can choose between authentication methods. The IVP bases itself on credential information of identities stored in the Identity Identification Storage Point and returns the result to the IdP Identity Identification Information Storage Point The Identity Identification Information Storage Point is a data store that contains credential, personal and contact information of the principal. The ISP is contacted by the IdP to provide attributes and by the IVP to verify the identity Identity Privilege Storage Point The Identity Privilege Storage Point (PSP) is a data store that contains privilege information regarding an identity: role assignments and all parameters and metadata of that assignment like expiry dates, parameter values, etc. 9

10 The PSP is contacted by the IdP to provide privilege information regarding an identity of a principal. 4.2 FAS Integration from Architecture Perspective Note: a technical component can fulfil multiple roles: In the integration scenario with a fedlet and the FAS, the fedlet will fulfil the role of an Access Control Policy Information Point and a Federation Service Provider. The Fedict Database acts as Identity Identification Storage Point and as Identity Privilege Information Point. The following image shows the different abstract components in the Fedict IAM Reference Architecture and the flow between the components. The principal tries to reach the application and the request gets intercepted by the session logic in the application, this is the coarse-grained PEP component. The PEP asks the PDP if the principal is allowed to access the application. If no information is present for the principal, the PDP will contact the PIP to obtain the necessary information of the principal. The Service Provider is configured within the Federation Circle of Trust of Fedict and trusts Fedict in regards to the identity of its principals and their privileges. The PIP will contact the Federation Service Provider who creates an authentication request for the Federation Identity Provider. The IdP determines the existence of session information of the principal and has to authenticate the principal. The principal is sent to the Identity Verification Point to determine the principal s identity based on information from the Identity Identification Storage Point. The necessary privilege information is 10

11 obtained from the Identity Privilege Storage Point to ensure that the IdP can send the identification and privilege information of the principal to the Service Provider in an Authentication Response. The Service Provider receives the authentication response and passes the identity and privilege information on to the Privilege Information Point. The PIP is now able to send this information to the Policy Decision Point, which can make a decision whether or not the principal is allowed to access certain logic of the application. This decision will be passed on from the PDP to the Policy Enforcement Point, which enforces the decision. 11

12 5 TECHNICAL 5.1 Introduction to SAML Assertions An assertion is a package of information that provides statements made by a SAML Authority. This can be an Identity Provider or a Service Provider. SAML Assertions are made about a Subject, represented by the <subject> element. The SAML 2.0 specification defines three kinds of assertion statements. All SAML-defined statements are associated with a subject. The three kinds of statements defined are as follows: Authentication Assertion: The assertion subject was authenticated by a particular means at a particular time. Attribute Assertion: The assertion subject is associated with the supplied attributes. Authorization Decision Assertion: A request to allow the assertion subject to access the specified resource has been granted or denied Protocols In the SAML specification you have multiple protocols. This document describes the three main protocols: Authentication Request Protocol The Authentication Request Protocol is used to send an <AuthnRequest> message element to a SAML Authority and request that it returns a <Response> message containing one or more assertions. These assertions must contain at least one authentication statement. Except for this requirement, the specific content of the returned assertions depend on the used profile or context of use. 12

13 Artifact Resolution Protocol The Artifact Resolution Protocol provides a mechanism to transport SAML protocol messages in a SAML binding by reference instead of by value. Both requests and responses can be obtained by reference using this protocol. An artificat is a small piece of data that must support a means by which the receiver can determine the sender. The most common use case for this mechanism is with bindings that cannot easily carry a message because of size constraints, or to enable a message to be communicated via a secure channel between the SAML requester and responder, avoiding the need for a signature Single Logout Protocol The Single Logout Protocol provides a message exchange protocol by which all sessions provided by a particular session authority are near-simultaneously terminated. The Single Logout Protocol is used either when a principal logs out at a session participant or when the principal logs out directly at the session authority. 13

14 When a principal logs out of his session either at a session participant or directly at a session authority, the session authority should send a <LogoutRequest> message to each session participant to which it provided assertions containing authentication statements under its current session and context with the principal. The session participant should, in return, answer with a <LogoutResponse> Bindings The following bindings are supported by SAML 2.0 SAML SOAP Binding (Limited support, only for artifact) Reversed SOAP (PAOS) Binding (Not supported) HTTP Redirect Binding HTTP Post Binding HTTP Artifict Binding SAML URI Binding (Not supported) For the Web Browser SSO and Single Logout profile, HTTP Redirect and HTTP Post bindings are most commonly used. The HTTP Artifact Binding works in conjunction with the SAML SOAP Binding which is used to retrieve the SAML Message by reference Profiles In SAML 2.0, the primary use case is still Web Browser SSO, but the scope of SAML 2.0 is much broader as shown in this exhaustive list of profiles: SSO Profiles o Web Browser SSO Profile o Single Logout Profile 14

15 Artifact Resolution Profile Metadata SAML profiles require agreements between system entities regarding identifiers, binding support and endpoints, certificates and keys, and so forth. To describe this agreement, the metadata specification is used. This specification defines an extensible metadata format for SAML system entities, organized by roles that reflect SAML profiles, e.g. SSO Identity Provider, SSO Service Provider, etc. <EntityDescriptor xmlns="urn:oasis:names:tc:saml:2.0:metadata" ID="I5bf4e6f87a221b0a" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" xmlns:ds= entityid="<entityid of RP >" xmlns:xsi=" xsi:schemalocation="urn:oasis:names:tc:saml:2.0:metadata <SPSSODescriptor AuthnRequestsSigned="true" protocolsupportenumeration="urn:oasis:names:tc:saml:2.0:protocol"> <KeyDescriptor> <ds:keyinfo> <ds:x509data> <ds:x509certificate><certificate of RP used for signing SAML messages (must be issued by a CA with a public OCSP)></ds:X509Certificate> </ds:x509data> </ds:keyinfo> </KeyDescriptor> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="<Endpoint Location for Single Logout Requests>" ResponseLocation="<Endpoint Location for Single Logout Responses (Optional)>" > </SingleLogoutService> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat> <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST" Location="<EndPoint Location for HTTP POST SAML Assertion Messages" index="0" isdefault="true"> </AssertionConsumerService> <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP- Redirect" Location="<EndPoint Location for HTTP Redirect SAML Assertion Messages" index="0" isdefault="true"> </AssertionConsumerService> </SPSSODescriptor> </EntityDescriptor> 5.2 Exchanged Attributes This section describes all the different attributes that are interchangeable through Fedict IAM. 15

16 The column Attribute gives the name of the attribute as within the SAML Response. The column Description gives more information about the attribute and the possible use. Attributes cannot be used in a different way as described. The exchanged attributes are defined on FAS for each Service Provider (during on boarding). There is a distinction between context aware attributes and context-free attributes Personal Information Most of these attributes are optional; they may not be available for all users. Attribute Description Identity Code <saml:nameid> The NameID code is a unique identifier for the principal during a session. FAS expects a transient NameID. This value changes each session per principal National Registry Number egovnrn The national registry number of the principal. This can be verified by an authentic source or obtained from the principal s eid card. Given Name givenname The given name of the principal. Can be registered in Fedict IAM or obtained from eid. Last Name surname The last name of the principal. Can be registered in Fedict IAM or obtained from eid. Personal address mail The personal address as registered in Fedict IAM. Preferred language PrefLanguage The preferred language of the principal as registered in Fedict IAM. FedID urn:be:fedict:iam:attr:fedid A unique value for the principal within a certain context. This value can be used as a unique identifier without the use of the national registry number. Context urn:be:fedict:iam:attr:context This is the context the principal is authenticated in. This can be one of the following values: urn:be:fedict:iam:context:citizen urn:be:fedict:iam:context:enterprise urn:be:fedict:iam:context:civilservant Authentication Method urn:be:fedict:iam:attr:authenticationmethod Contains the used authentication method. This allows applications to offer different functionalities based on authentication method Privilege Information Attribute Roles roles 16 Description This attribute holds all the role information for the principal specific for the Relying Party. The

17 5.2.3 Metadata Information Metadata information in authentication request information is base64 encoded and has an XML structure. More details can be found in section Attribute Requested Authentication Method <samlp:requestedauthncontext> Authentication Comparison <samlp:requestedauthncontext xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" Comparison="exact"> Force Authentication <samlp:authnrequest ForceAuthn="false true"> NameIDPolicy <samlp:nameidpolicy Format="urn:oasis:names:tc:SAML:2.0:nameidformat:transient"> Authentication Request code <samlp:authnrequest ID="s b1a1e04ae81872a1ef ee9835" Issuer <saml:issuer> Description This refers to the requested authentication method. This allows applications to offer different functionalities based on authentication method. This should be Exact. The principal must authenticate with one of the requested authentication methods. A Service Provider can request to authenticate the principal even when an active session is available. This attribute controls the Single Sign On behaviour of FAS between multiple Relying Parties within the Fedict Circle of Trust and within a certain context. This default value is False. Changing this to true does not mean that you can allow another user to authenticate if a session exists. This setting is used to verify the identity of the existing user. Only the transient format is allowed. A unique identification number of the request The unique identifier of the Service Provider (entityid described in the metadata of the Service Provider) within Fedict IAM Metadata information in authentication response Attribute Authentication Result <samlp:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> Timestamp <saml:authnstatement AuthnInstant=" T13:30:21Z"> Audience of the response <saml:audience> Description The result of the authentication when successful. The principal isn t redirected to the SP on failure. Exact timestamp of authentication The Relying Party for which the assertion is valid. 17

18 dience> Reference to the Authentication request code <saml:subjectconfirmationdata InResponseTo="s b1a1e04ae81872a1ef ee9835"> Session ID <saml:authnstatement SessionIndex="s2a3fdc6b889dd844a06c3ae354963d65 6fe82dd15"> Reference to the authentication request of the Relying Party to which FAS responds. A unique identifier of the principal s session on the Fedict IAM system. 5.3 Syntax details Authentication Method The Service Provider needs to request one or more authentication contracts in the Authentication request through the use of the SAML Attribute AuthenticationContext. It is important to request the correct authentication contract as this is used to provide attributes, roles. If the necessary contract isn t included in the request this isn t method shown during authentication. The authentication contract is constructed of two elements. The authentication mean and the principal s context. The context of the principal can be citizen, enterprise or civil servant. The following table describes the structure of the AuthenticationContext. Prefix Context Authentication mean Authentication Contract urn:be:fedict:iam:fas citizen eid urn:be:fedict:iam:fas:citizen:eid token urn:be:fedict:iam:fas:citizen:token enterprise eid urn:be:fedict:iam:fas:enterprise:eid token urn:be:fedict:iam:fas:enterprise:token It is possible to request multiple authentication means and/or contexts. The order in which the requested contracts are sent is used by FAS. The first option will be the pre-selected authentication contract. All other contracts are listed as other options for the principal. If there are contracts requested with multiple contexts, the user will need to make an explicit choice of context when logging on. The SAML authentication response will contain the used authentication context Structure of Privilege Information Fedict IAM delivers privilege information as base64 encoded xml. This information is delivered through the roles attribute in the SAML response. The XML format uses a schema to deliver the role information with a set attribute role-name and one or more possible parameters. <rol:roleresult xmlns:rol=" <rol:role name="<applicatie_rol>" xmlns:rol=" <rol:roleattribute name="companyid"> </rol:roleattribute> 18

19 <rol:roleattribute name="fedictdomain">somedomain</rol:roleattribute> </rol:role> </rol:roleresult> The above information is available as a base64 encoded value in the SAML response in the roles attribute. The above role information results in the following value: PHJvbDpSb2xlUmVzdWx0IHhtbG5zOnJvbD0iaHR0cDovL2JlLmZlZGljdC5yb2xlbWdtdC9Sb2xlWE1MU2NoZW1hIj4NCgk8cm9sOlJvbG UgbmFtZT0iPGFwcGxpY2F0aWVfcm9sPiIgeG1sbnM6cm9sPSJodHRwOi8vYmUuZmVkaWN0LnJvbGVtZ210L1JvbGVYTUxTY2hlbWEiPgkJ CQk8cm9sOlJvbGVBdHRyaWJ1dGUgbmFtZT0iQ29tcGFueUlkIj45OTk5OTk5OTk8L3JvbDpSb2xlQXR0cmlidXRlPg0KCQk8cm9sOlJvbG VBdHRyaWJ1dGUgbmFtZT0iRkVEaWN0RG9tYWluIj5TT01FRE9NQUlOPC9yb2w6Um9sZUF0dHJpYnV0ZT4NCgk8L3JvbDpSb2xlPg0KPC9y b2w6um9szvjlc3vsdd4= 5.4 Request and Response Examples Authentication In the simplest of scenarios the Service Provider asks a certain AuthenticationContext for a session of the principal and the FAS delivers certain identity attributes, no privilege information to the Service Provider. A typical request looks as follows. The important attributes are highlighted. ForceAuthn, Issuer, NameIDPolicy and RequestedAuthnContext. <samlp:authnrequest xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" ID="s f77b ef3c1c3ad7038ec635ab9a" Version="2.0" IssueInstant=" T19:00:14Z" Destination=" ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL=" <saml:issuer xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">fedlettest1</saml:issuer> <ds:signature xmlns:ds=" <! - signature information removed of readability --> </ds:signature> <samlp:nameidpolicy xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" SPNameQualifier="FedletTest1" AllowCreate="true"></samlp:NameIDPolicy> <samlp:requestedauthncontext xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" Comparison="exact"> <saml:authncontextclassref xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">urn:be:fedict:iam:fas:citizen:eid</saml:authncontextcla ssref> <saml:authncontextclassref xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">urn:be:fedict:iam:fas:citizen:token</saml:authncontextc lassref> </samlp:requestedauthncontext> </samlp:authnrequest> A typical response would look as follows. The important attributes are highlighted. 19

20 Combination of Destination, ID and InResponseTo are used to prevent replay attacks and abuse of captured responses. The Status Code The AuthnContext The content of the attribute statement (all information within <saml:attributestatement>) <samlp:response xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" Consent="urn:oasis:names:tc:SAML:2.0:consent:obtained" Destination=" ID="idEgYuquDWiDQypa6K1U0JaSk-x8s" InResponseTo="s f77b ef3c1c3ad7038ec635ab9a" IssueInstant=" T19:00:15Z" Version="2.0"> Logout A typical LogoutRequest looks as follows: <samlp:logoutrequest xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" ID="s2d1cdf8aa8b3063edb026b7ce86efda77ed52417b" Version="2.0" IssueInstant=" T19:35:27Z" Destination=" > <saml:issuer xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion"> /</saml:issuer> <saml:nameid xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" NameQualifier=" SPNameQualifier=" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" >myns4tj12s7i6ow3ggk6ua7fvb/a</saml:nameid> <samlp:sessionindex xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol">s21d f0c526f9591e d0485ba112</samlp:SessionIndex> </samlp:logoutrequest> A typical LogoutResponse looks as follows: <samlp:logoutresponse xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" ID="s63732ba858c3fd3c394faf58f3fa4833de1a9727" Version="2.0" IssueInstant=" T19:35:27Z" Destination=" InResponseTo="s2d1cdf8aa8b3063edb026b7ce86efda77ed52417b" > <saml:issuer xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion"> 20

21 <samlp:status xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol"> <samlp:statuscode xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:status> </samlp:logoutresponse> Both Request and Response message are signed. 21