Tusker IT Department Tusker IT Architecture

Transcription

1 Tusker IT Department System Overview Documents Tusker IT Department Tusker IT Architecture Single Sign On Overview Page 1

2 Document Information and Approvals VERSION HISTORY Version # Date Revised By Reason for change /05/2012 Drav Sloan (DS) Start of the rewrite of document /06/2012 DS & Chris Khalil Proof reading and rephrasing of overview /02/2014 DS Addition of SAML and process. Details of the implementation process. DOCUMENT APPROVALS Approver Name Project Role Signature/Electronic Approval Date Nicola Beard Technical Document Author 10/02/2014 Page 2

3 Contents Document Information and Approvals Overview SSO Mechanisms and Process Flow Connections Using the Proprietary SSO Mechanism Connections Using SAML Process Continuation Shared by Both Mechanisms Implementation Process Generation of Public/Private Key Pairs Assertion/Token Fields Tusker Proprietary SSO Fields Tusker SAML Fields Testing, QA and UAT Go Live of the Provider and Its SSO with Tusker Technical Details The Tusker Proprietary SSO Mechanism The Tusker SAML Mechanism (Non-Encrypted Assertion Statement) The Tusker SAML Mechanism (Encrypted Assertion Statement) Appendix A A.1 Tusker Proprietary SSO Mechanism XML Example A.2 Tusker SAML Assertion Statement Example (No Encryption) A.3 Tusker SAML assertion statement example (with encryption) Page 3

4 1.0 Overview When you create an account to access a website without Single Sign On (SSO), generally those login details will work on that site only. Websites using SSO allow you to use one account to access many websites by entering only a single set of login details. In an example case of Benefits Providers, users will log into the Benefits Provider s website and follow a link to the Tusker website. At this point the Benefits Provider s website will pass a specific SSO token to Tusker. This token allows Tusker to perform security checks, validate data integrity, and allow the benefits provider to pass on relevant data such as driver credentials and what Company the user is employed by. This is all through one webpage link. The security checks are done without user interaction, and if successful the driver will be referred to their Tusker Driver Journey Homepage. Some benefits of using SSO are: Seamless integration of two websites without requirement for more usernames and passwords Secure and encrypted login mechanisms Avoid the pitfalls of Password Fatigue. 2.0 SSO Mechanisms and Process Flow Tusker presently utilises two different mechanisms to enable the SSO process, a proprietary method and one based around the SAML 2.0 specification. Both methods follow the same basic process and achieve the same end result, but use different underlying mechanisms to deliver the data content. Security Assertion Markup Language, or SAML for short, is predominantly the preferred mechanism for SSO assertion on Windows Server platforms. This is usually because the NET framework 4.5 has native support for SSO/SAML and there are also a number of libraries which reduce the amount of work required to deliver a working product. It is also a ratified standard and as such has a specification which can be used as a guideline for understanding its mechanisms and designing systems from the ground up. There are plenty of vendor and programming language specific SAML libraries such as simplesaml.php for PHP and OpenSAML for Java. There is also a list of SAML related products maintained on Wikipedia. Both provide the same core features: Encryption of the data. Tamper-proof data validation using cryptographic key signing of the tokens. An expiry date built into the token, so the tokens inherently have a short life span. Flexible content of the data section of the token, to allow the communication of relevant user credentials, and company specific information from one service to another. Page 4

5 2.1 Connections Using the Proprietary SSO Mechanism The process flow of an external provider or service attempting connection to the Tusker Driver Journey Homepage via the proprietary SSO mechanism is as follows. A user clicks a link at the external service site which leads to Tusker. The external service creates a token specific for that user, encrypts it and submits it to Tusker via a prearranged SSO CGI URL. Tusker checks for 3 values submitted to its SSO CGI form (encrypted message, key and signature). If all three are provided, the key is validated against the public half of the cryptographic key pair that the partner generated and provided Tusker (see Section 3.0 for the steps for creation of the public/private key pair). If valid, the encrypted message is cryptographically validated against the provided signature value. This validates the integrity of the data contained inside the token. If the signature value validates, the encrypted message is then decrypted and the xml that results is processed and the user data extracted from it. The process at this point continues in Section 2.3. Figure 1: Tusker SSO input process flow. Page 5

6 2.2 Connections Using SAML The process flow of an external provider or service attempting connection to the Tusker Driver Homepage via the SAML SSO mechanism is as follows. A user clicks a link at the external service site which leads to Tusker. The external service creates a SAML Assertion specific for that user, if desired, encrypts the data segment, signs the assertion and submits it to Tusker via a prearranged SAML SSO CGI URL The CGI checks for a posted variable submitted to its form (called SAMLResponse) The SAMLResponse is base64 decoded into an assertion. The assertion is decrypted if it is encrypted. The digital signature of the assertion is checked against the public half of the cryptographic key pair the provider will have provided Tusker (see Section 3.0 for the steps for creation of the public/private key pair) The assertion s data integrity is validated by checking the provided digest to the content of the assertion. If the signature is valid, the AtrtributeStatement is processed and the user s data is extracted from it. The process at this point continues in Section 2.3. Figure 2: Tusker SAML input process flow. Page 6

7 2.3 Process Continuation Shared by Both Mechanisms The timestamp field is checked to make sure the token has not expired. If the token has not reached its end of life, Tusker checks that the token has the mandatory fields present (see section 4 for details on the mandatory fields required for the SSO). The fields provided are then ratified to requirements such a maximum field size. The companycode is extracted from the token and the relevant company on Tusker s system located. This company configuration is checked to have mandatory configuration options such as a Default Fleet Manager and Default Driver Band. If the tokens values pass all tests, then either an existing user account is located or a new one is created. Accounts will be located by using the companycode and userid provided in the token data. An account will be automatically created if Tusker s system does not have a user account which matches these two credentials. This is always the case on an individual s first visit to the Tusker website. The user account is then redirected to their own personalised Tusker Driver Homepage. 3.0 Implementation Process Both Tusker and the partner will have to allocate development time to create the initial SSO link. The process of implementing the SSO involves several steps. They will both need to coordinate private/public key pair generation and exchange, discuss the requirements (if any) of inclusion of additional fields in the token, and whether the additional fields are included in the report. Tusker will also provide a URL for entry point into the Tusker SSO system. Once this initial process has been developed, tested and put into service, adding SSO links for specific companies is then a much more simple process. This consists of creating a unique identifier for a company so that Tusker can program our systems to direct the driver to the correct Driver Homepage for their company. 3.1 Generation of Public/Private Key Pairs Using OpenSSL a public/private pair can be created using the following commands. Create a certificate signing request (CSR) and a password-protected private key: openssl req -new -out provider.csr -keyout provider.pem Create a copy of the private key without password protection: openssl rsa -in provider.pem -out provider.key Generate a self-signed certificate from the CSR: openssl x509 -in provider.csr -out provider.cert -req -signkey \ provider.key -days 3650 The provider.cert is then sent to Tusker. The provider.key should be protected from visibility to the outside, as it is used in the digital signing of the tokens sent to Tusker. If an outside person were to get a copy they could use it to gain unauthorized access to SSO process. Page 7

8 Microsoft users can use makecert, SelfSSL (from the IIS 6.0 Resource Kit compatible with IIS7) or similar tools to generate a private key and public certificate pair. 3.2 Assertion/Token Fields Depending on the mechanisms being used, and the requirements of the client being implemented, the contents of the assertion will vary. For example, certain clients have a requirement to be placed in specific company bands on login, or require posted back information, or need us to store other additional information pertaining to the user being processed. These quite often require additional development for these fields to be acted upon. However, the two SSO mechanisms do have standard fields which are detailed below Tusker Proprietary SSO Fields A token generated for the Tusker Proprietary SSO mechanism requires the following XML fields: Name Mandatory? Type Length Description companycode Yes Text 100 userid Yes Text 100 firstname Yes Text 100 surname Yes Text 100 address Yes Text 100 staffnumber No Text 100 Contains a unique identifier for the company of the SSO user, which links it to the appropriate company in Tusker. Contains a unique identifier per company - of the SSO user. Contains the first name of the SSO user. Contains the surname of the SSO user. Contains the address of the SSO users Unique number, often payroll related, to the SSO user Tusker SAML Fields An assertion generated for the Tusker SAML mechanism requires the following attribute statement attributes: Page 8

9 Name Mandatory? Type Length Description companycode Yes Text 100 userid Yes Text 100 firstname Yes Text 100 surname Yes Text 100 address Yes Text Testing, QA and UAT Contains a unique identifier for the company of the SSO user, which links it to the appropriate company in Tusker. Contains a unique identifier per company - of the SSO user. Contains the first name of the SSO user. Contains the surname of the SSO user. Contains the address of the SSO users. Once keys have been exchanged, and assertion/token fields agreed and developed a test URL is created for both parties to test integration of the two sites SSO mechanism. This test site is on a test database and website, so can be tested without worry of affecting live services and customers. The aim of this part of the process is to gain sign off on Quality Assurance and to do any required User Acceptance Testing. 3.4 Go Live of the Provider and Its SSO with Tusker The next stage is to set the provider link live on Tuskers main website, which involves some configuration on our BackOffice service, pushing of any code changes and the associated public half of the key pairs to our live services. A new live URL for connections to Tusker through the SSO mechanism will then be provided. Page 9

10 4.0 Technical Details The details of the two processes and what needs to be created/generated are detailed in this section. 4.1 The Tusker Proprietary SSO Mechanism Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Generate a random string (8-bit binary) of 24 bits length. This is known as the symmetric key (k). This should be generated for each token passed to Tusker. Generate a random string (8-bit binary) of 8 bits length. This is known as the Initialization Vector (IV). This should be generated for each token passed to Tusker. Base64 encode k and IV, and place them in a string in the form: key=xxx; iv=yyy; So you end up with something like: key=yuo1jvewd8vi44rmm/w5lzluhgcugwtk; iv=hmihgulbpr8=; Using Public key algorithm (RSA) encrypt the Base64 string using the public half of the Tusker key pair, provided in certificate form. Generate a signature of this RSA encoded string, using the private half of Providers Certificate key pair. Generate the XML token containing the user s details, including the mandatory fields set out in section Using Triple-DES Cipher, using k as the symmetric key and IV as the Initialization Vector encrypt the XML document. Base64 encode the string in Step 3, this will be known as the encryptedkey. Base64 encode the RSA encrypted string in Step 4, this will be known as the signature. Base64 encode the Triple-DES encrypted XML statement, this will be known as the encryptedmessage. POST to the Tusker SSO URL, setting the post variables encryptedkey, signature and encryptedmessage (with the values set to those detailed above). 4.2 The Tusker SAML Mechanism (Non-Encrypted Assertion Statement) Tusker s framework only supports the Security Assertion Markup Language version 2, detailed at the open oasis webpages. Page 10

11 Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Generate a saml:attributestatement with the attributes detailed in section Create a SAML Response statement (samlp:response), containing a saml:assertion, with an ID attribute unique to that specific assertion. The saml:assertion should contain a saml:condition that sets the attributes NotBefore and NotOnOrAfter, both of which are set to an ISO 8601 Zulu date format. The NotBefore attribute should set to a Zulu time 5 minutes in the past and the NotOnOrAfter attribute to the Zulu time you want the statement to be valid until (usually 10 minutes in the future). The XML fragment containing the saml:assertion is then signed using the XML Digital Signature standard. The signature must also contain a digest of the fragment being signed and the transformation method utilized. The Signature XML is inserted inside the saml:assertion statement. The samlp:response is then base64 encoded and sent to tusker using a POST submission. The contents of this base64 encoded statement should be set on the SAMLResponse POST variable. 4.3 The Tusker SAML Mechanism (Encrypted Assertion Statement) Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Generate a saml:attributestatement with the attributes detailed in section Create a SAML Response statement (samlp:response). Create a saml:assertion fragment, with an ID attribute unique to that specific assertion, and insert the saml:attributestatement. Encrypt the saml:assertion fragment using the mechanism detailed in the XML Encryption Syntax and Processing specification. Presently Tusker support the rsa-1_5 and aes256-cbc encryption methods. The symmetrical cypher key should be supplied in the saml:encryptedassertion/ EncryptedData/EncryptedKey/KeyInfo/CipherData XPath. The encrypted data should be contained inside the saml:encryptedassertion/encrypteddata/cipherdata XPath. The saml:encryptedassertion should then be inserted into the samlp:response Step 7 The XML fragment containing the saml:encryptedassertion is then signed using the XML Digital Signature standard. The signature must also contain a digest of the fragment being signed and the transformation method utilized. Step 8 The Signature XML is inserted inside the saml:assertion statement. Page 11

12 Step 9 The samlp:response is then base64 encoded and sent to tusker using a POST submission. The contents of this base64 encoded statement should be set on the SAMLResponse POST variable. Page 12

13 Appendix A A.1 Tusker Proprietary SSO Mechanism XML Example. An example of the Tusker SSO mechanism s XML before encoding is as follows: <?xml version="1.0" encoding="utf-8"?> <logindata> <userid> </userid> <companycode>xyz123</companycode> <userid> </userid> <firstname>fred</firstname> <surname>smith</surname> < address>fred.smith@example.com</ address> <timestamp> t12:40:25z</timestamp> </logindata> Page 13

14 A.2 Tusker SAML Assertion Statement Example (No Encryption) An example of the Tusker SAML assertion, without encryption, is as follows: <?xml version="1.0"?> <saml:assertion xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" Version="2.0" ID="_faeeb326-efca-4a88-bb77-1d d13" IssueInstant=" T15:48:29Z"> <saml:issuer Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity"> > <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI="#_faeeb326-efca-4a88-bb77-1d d13"> <Transforms> <Transform Algorithm=" <Transform Algorithm=" <InclusiveNamespaces xmlns=" PrefixList="#default saml ds xs xsi"/> </Transform> </Transforms> <DigestMethod Algorithm=" <DigestValue>ODy9/ZBgqbLrUi2e9fdd4MpDAtQ=</DigestValue> </Reference> </SignedInfo> <SignatureValue>wRqELB7X/SMKESiDcApnzTbasw1i0eoMDbGBirGE8uSZmqhK1cSRF20EnA8 AVySXIvkEA98it45w4clDPqryUTizkeQfCyIvlk5GJR6Z13MTwBrOlbJFYnbqHHcH8Z8j7EO8EO E5GRydShLf/FpDOedUcBnqEsddvIcwOebmLsc=</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIB2TEyMzEyMzU5NTlaMDUxMzAxBgNVBAMeKgBUAEIAWABfAFMAQQBNAE wamgbfaekazabqaf8avablahmadabpag4azzcbnzanbgkqhkig9w0baqefaaobjqawgykcgyeaw uaghl14+0gwht8ls3w9l8l4mfuhtieaqccb3vlfyetxvgviwmqbh9k4hpw30hmyepsbdd+r3pst SJovcZ+FVDaSZEPZdb0WNT+7STMiV91xVTDbRK4zUGFoxUTu99CV/9nJvvHCeuNUAkJGgn9aVJh EbAJOlCaAe6BJUVKh8OUCAwEAAaNLMEkwRwYDVR0BBEAwPoAQEuQJLQYdHU8AjWEh3BZkY6EYMB YxFDASBgNVBAMTC1Jvb3QgQWdlbmN5ghAGN2wAqgBkihHPuNSqXDX0MA0GCSqGSIb3DQEBBAUAA 0EAMvQOfC24ELwXPgiXP3YrGUSAguSyNAyikMD+0wUuABAUVOwi1Orz2Y3RIGO8XIy/YBdq+2h5 mmi2cieopeo35g==</x509certificate> </X509Data> </KeyInfo> </Signature> <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:2.0:nameidformat:persistent">137371</saml:NameID> </saml:subject> <saml:conditions NotBefore=" T15:38:29Z" NotOnOrAfter=" T15:58:29Z"/> <saml:authnstatement AuthnInstant=" T15:48:29Z"> Page 14

15 <saml:authncontext> <saml:authncontextclassref>urn:oasis:names:tc:saml:2.0:ac:classes:internetp rotocolpassword</saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute Name="companyCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>562</saml:attributevalue> </saml:attribute> <saml:attribute Name="userId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>test019</saml:attributevalue> </saml:attribute> <saml:attribute Name="firstName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>test019</saml:attributevalue> </saml:attribute> <saml:attribute Name="surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>test 119</saml:AttributeValue> </saml:attribute> <saml:attribute Name=" Address" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue>xx</saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> Page 15

16 A.3 Tusker SAML assertion statement example (with encryption) An example of a Tusker SAML Assertion with encryption is as follows: <?xml version="1.0"?> <samlp:response xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" ID="_1c3bc6ec-7d4d-4495-a a440eb365" Version="2.0" IssueInstant=" T13:22:33Z" Destination=" <saml:issuer xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">urn:example_sso</saml:is suer> <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI="#_1c3bc6ec-7d4d-4495-a a440eb365"> <Transforms> <Transform Algorithm=" <Transform Algorithm=" <InclusiveNamespaces xmlns=" PrefixList="#default samlp saml ds xs xsi"/> </Transform> </Transforms> <DigestMethod Algorithm=" <DigestValue>aM8w7DRKsq3StzwwP3I9M75rb9A=</DigestValue> </Reference> </SignedInfo> <SignatureValue>fyRiC3zTTqF1FoHhtcBiQDmi7HN6p7JZdoGeBpuid/wHMX4HQmLw1SEtate /CWXSecftsOLpBN4N6kv+/6UqJlQ6x/DMsLL8KlJWFOea4RHhqEtpZOjRzRHuRJoFFIXdY=</Si gnaturevalue> <KeyInfo> <X509Data> <X509Certificate>MIIFIzCCBAugAwIBAgIRAILDN6EEyhbIIu7nP+AFaWMwDQYJKoZIhvcNAQ EFBQAwgYkxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVB AcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMS8wLQYDVQQDEyZDT01PRE8g SGlnaCBBc3N1cmFuY2UgU2VjdXJlIFNlcnZlciBDQTAeFw0wOTEyMTAwMDAwMDBaFw0xMTEyMTA ymzu5ntlamighmqswcqydvqqgewjhqjerma8ga1ueermirum0wsa4qkixdzanbgnvbagtbkxvbm RvbjEPMA0GA1UEBxMGTG9uZG9uMRswGQYDVQQJExI4IFNhbGlzYnVyeSBTcXVhcmUxDTALBgNVB AoTBEtQTUcxETAPBgNVBAsTCEVsaXRlU1NMMR4wHAYDVQQDExVwb3J0YWwucmV3YXJkd2lzZS5j b20wgz8wdqyjkozihvcnaqebbquy2vtzwn1cmvtzxj2zxjdqs5jcnqwjayikwybbquhmaggggh0 dha6ly9vy3nwlmnvbw9kb2nhlmnvbta7bgnvhreendayghvwb3j0ywwucmv3yxjkd2lzzs5jb22 CGXd3dy5wb3J0YWwucmV3YXJkd2lzZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAEFp2OQeWyjTsD cxfnabenwmikesmngj5nzq6vl7owpnh0h9qi1lo998cgvjjptuvhrfbb12egffwpe00emb1f3ho cxo16yi9boo7zhiygwhs3zq4hfu6ersloi5mydopvyii0s4vpnuptrydnv3cpezmropa0lyzgzy r2uded7br5hpe8dpxyopaw5hju2szwkajy4pw9brpnhuvwxg9ccz3cqvqssyl6hh1dgkvi/zqwc zyq5r3ad43kq/6ipss12rmjiwo24kabgzdljaathyr9c+det70dx3p4gf3py171yoth9rq7w3me lkxfu3qth6ifxbhumcgvudrtg7egk=</x509certificate> </X509Data> </KeyInfo> Page 16

17 </Signature> <samlp:status> <samlp:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:status> <saml:encryptedassertion xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion"> <EncryptedData xmlns=" Type=" <EncryptionMethod Algorithm=" <KeyInfo xmlns=" <EncryptedKey xmlns=" <EncryptionMethod Algorithm=" <KeyInfo xmlns=" <X509Data> <X509Certificate>MIIEFDCCA32gAwIBAgIJAPQZCazXco7WMA0GCSqGSIb3DQEBBQUAMIG0MQ swcqydvqqgewjhqjewmbqga1uecbmnsgvydgzvcmrzaglyzteqma4ga1uebxmhv2f0zm9yzdedm BsGA1UEChMUVHVza2VyZGlyZWN0IExpbWlkbWluQHR1c2tlcmRpcmVjdC5jb20wgZ8wDQYJKoZI hvcnaqebbqadgy0amigjaogbalqj2jk3nmbfq+iaiomfkospunoosyvzbwrczshjn4adtighejd EcLNuJR3AQlFsOjGjfvhupfmlNe0g5LNdRJtjf0b1z9h3sRtuHBQ1xGhNaJYOJRJVERO0/+Kn7G 1ZtQHXDzPqsafdT4AaHohvmiZdAfIVrv0k8QynM3z7Z+21AgMBAAGjggEqMIIBJjAdBgNVHQ4EF gqueljay6fddyft6wq5jrqukfral4iwgekga1udiwsb4tcb3oaueljay6fddyft6wq5jrqukfra l4khgbqkgbcwgbqxczajbgnvbaytakdcmrywfaydvqqiew1izxj0zm9yzhnoaxjlmrawdgydvqq HEwdXYXRmb3JkMR0wGwYDVQQKExRUdXNrZXJkaXJlY3QgTGltaXRlZDEMMAoGA1UECxMDU1NPMS QwIgYDVQQDExtzczRjOS5iZXRhLnR1c2tlcmRpcmVjdC5jb20xKDAmBgkqhkiG9w0BCQEWGXNzb GFkbWluQHR1c2tlcmRpcmVjdC5jb22CCQD0GQms13KO1jAMBgNVHRMEBTADAQH/MAsGA1UdDwQE AwIF4DANBgkqhkiG9w0BAQUFAAOBgQB6zr2437ZvU1eRzjyg1MkkNAuvDhKH/H9/zS9IRAlv+I2 2CeCnutBFF22L85nddTMcGuW0FCe6PREm2gsprCLDqklr193DuXI7crUDo3K0Z3atXo5+zZYg0b azjb/wui7rd/lnjhvgkcya0tv1m4l6hazclimcelmfk3srhxlpzg==</x509certificate> </X509Data> </KeyInfo> <CipherData> <CipherValue>j917khlamwwnnmbcxWDjB/bpsMuZe3G1CGV4KUFugKXbnrGnaIlG+0PSqi6mLh 3YBB+zkInotcYGPl5DEwoCsKDluXF8FQB5C/aRZpdoPDcRK76XpzyGdXo2jGxrTLyePP1/OX3XN qusqw=</ciphervalue> </CipherData> </EncryptedKey> </KeyInfo> <CipherData> <CipherValue>vvHkABqCzjdY7wIRjtV3ZHGMZN5r2Rb+6kXZSGQGIG8oE3lktjPjngsDUHCUX3 misbqthvkf3pl/ck9ml4muvufumkhrzxtzghufhwvcv0j7/qbddrzfvtpi3zt8xpswxfojddkkt Lue23H5+/nd49JALUiK97rZwnZ6jGk52AxWjsp4D3yFt0WkUkuCoDJAZAJuXeXb99Bs532SB1P7 YaS7iPGe5XjGER6rOGOF6C05jzGQSi2BAMBxeHx6NvKSSrh+lMLGCBUvKXs4AkOjYH7S3waSgKw TshajZ4BzWGII0DjBIQ+5KFPmzySJ3LsSMUXR/sRCBrsQ4q1NEL+H202myAPi7H3w8mFehN5pD7 FtW5sr3bpd1d5WKjloPzMpjN9zpTMyiUvROmcusHwsKTvh2L6y+FKqRn7TF5S4qsN1+9KG0KTy/ PRQCcC4NmKCxXkK/HnsqfcuW0xQzjeOkpGcnO+hc8klu6qGofzYLdMIXmic5jKyjOUTtig+yzjX an+xfpy3dottndyo+hqhhmqyhbutup0qxkwueeriuwvxbwgiwkei0uu/ggablpprny2admwj5fs 1Ye++PlDU86EGy6gRh0aeYE+xQwOB5CO1m2PtgBfVZ8ED3h8lCBwUI5nbmgvB3HLQa9H35JrphD WlVj2ceB3qJAutXi8PH+uJVgCZOZMcfu7lDywvJ9l/MOxy5v49DpeEVP//H8DfSu5tRf8kBAe7g Xhecfo8khP5nvi7WSoqVhSoE5jyMI+0wAGjxDhWyTLCWxveN+bQW857Uj3vGHLEPLNtPrw3TpMa yw785lmzkt8fkfpzfhue2smw284pepmeblmcokrht9mqilzpl6vr3eyaewiv9jqi2kryqnmrnlk tfrhifean3shu+nmagjy1luif06b1n8ketxvi7jmn0xztglharq4viirupispbxveat9ek7chbl OT8OyvRLam3huO1ry1ldjPAS6bNTDkJdfvPNdHvE2cclcKrQJmKV+8Rhj6fN17AVm0iFXFn43OK KqRG5WxYyjbactjD3pnXL1lhWmPufd4Y7IZVKq70VL8UU4bzmdq61q0Gy1vkaRDLE2ZwD7O1DJx Page 17

18 DoeUkvLdwBDGyBmUFHBamUJ9g0ppH8LQHW4UGcUvTtdIeAgMGFV/4cTZ+rqMpqBSFzlT4a7H/ed HtEk3CglB2Mgfw+V5mUGxedUMaIaqwDPOc/T+PFNJzFCGrlFY+wVZiauLdXQR1shMv8Cz+A==</ CipherValue> </CipherData> </EncryptedData> </saml:encryptedassertion> </samlp:response> Page 18