How to use ldap realm for authorisation for SAML realm

Hi team,

I have ldap realm configured to allow access to elasticsearch APIs. I also have SAML configured for kibana.
Now I want to setup user authorisation in saml using ldap realm instead of api based role mapping. I read this in elastic documentation _;

If your users also exist in a repository that can be directly accessed by Elasticsearch (such as an LDAP directory) then you can use authorization realms instead of role mappings.

In this case, you perform the following steps: 1. In your SAML realm, assigned a SAML attribute to act as the lookup userid, by configuring the attributes.principal setting. 2. Create a new realm that can lookup users from your local repository (e.g. an ldap realm) 3. In your SAML realm, set authorization_realms to the name of the realm you created in step 2.

My configuration -

xpack.security.authc.realms.saml1:
type: saml
order: 2
idp.metadata.path: /usr/share/elasticsearch/config/saml/idp-metadata.xml
idp.entity_id: "mineSSO"
sp.entity_id: "{entity_id}"
sp.acs: "{acs}"
sp.logout: "{logout}"
attributes.principal: "nameid:persistent"
encryption.key: /usr/share/elasticsearch/config/saml-cert/tls.key
encryption.certificate: /usr/share/elasticsearch/config/saml-cert/tls.crt
xpack.security.authc.realms.ldap1:
type: ldap
order: 0
url: "ldap://corpds.mine.com:389"
user_dn_templates:
- "uid={0},ou=people,o=mine.com,o=email"
group_search:
base_dn: "ou=groups,o=mine.com,o=email"
filter: uniqueMember={0}
files:
role_mapping: /usr/share/elasticsearch/config/role_mapping.yml
unmapped_groups_as_roles: false

role_mapping.yml: |
click_admins:
- "cn=GBI APC Infra,ou=groups,o=mine.com,o=email"
- "uid=rgujral,ou=people,o=mine.com,o=email"
roles.yml: |
click_admins:
run_as: [ 'clicks_watcher_1' ]
cluster: [ 'monitor' ]
indices:
- names: [ 'events-*' ]
privileges: [ 'read' ]
field_security:
grant: ['category', '@timestamp', 'message' ]
query: '{"match": {"category": "click"}}'

So I know I have to add authorisation_realms: ldap1 under saml realm but what should be the value for attributes.principal ?

attributes.principal needs to specify a SAML attribute (or nameid) that matches exactly with the userid you use in LDAP.
That is, something that your SAML IdP sends to ES that we can substitute into uid={0},ou=people,o=mine.com,o=email in order to get the correct DN for the LDAP bind.

Without knowing what your SAML setup looks like, I can't give you any more details than that.

@TimV , my saml setup is below -

xpack.security.authc.realms.saml1:
      type: saml
      order: 2
      idp.metadata.path: /usr/share/elasticsearch/config/saml/idp-metadata.xml
      idp.entity_id: "IDPSSO"
      sp.entity_id: "{entity_id}"
      sp.acs: "{acs}"
      sp.logout: "{logout}"
      attributes.principal: "nameid:persistent"
      encryption.key: /usr/share/elasticsearch/config/saml-cert/tls.key
      encryption.certificate: /usr/share/elasticsearch/config/saml-cert/tls.crt 

IDP supplies username in the form "anyname@mine.com"
I can map users by below mapping-

_security/role_mapping/saml-kibana-rajesh" -H 'Content-Type: application/json' -d'

{

"roles": [ "superuser" ],

"enabled": true,

"rules": { "all": [

{ "field": { "realm.name": "saml1" } },

{ "field": { "username": "jack_thomas@mine.com" } }

]}

}’

How can I provide the same in attributes.principal ?

I'm sorry, I don't understand the question.

You said you want to configure your SAML realm to delegate authorization to the LDAP realm. to do that you need to have an exact match in userids.

Does your SAML IdP provide something that you can match to the uid in your LDAP realm?

@TimV I enabled trace logging in saml to capture saml request and response

PUT /_cluster/settings
{
  "transient": {
    "logger.org.elasticsearch.xpack.security.authc.saml": "trace"
  }
} 

I'm not getting complete details of response i.e who tried accessing, what attributes.

cat es-coordinating.log |grep "samlp:Response"
[2019-06-11T10:36:53,136][TRACE][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] Received SAML Message: <?xml version="1.0" encoding="UTF-8"?><samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Destination="https://gbiobserver-events-dev.corp.mine.com:443/api/security/v1/saml" ID="A357baad0-b841-4a6b-bc88-a542f544f298" InResponseTo="_91c443e3523d0b1b8be50cace15c3792b56f2ec2" IssueInstant="2019-06-11T10:36:51.000Z" Version="2.0">

I'm able to map individuals to SAML with their mail IDs  { "field": { "username": "rgujral@mine.com" } }
 but not groups (group attribute is enabled by IDP)  { "field": { "groups": "10606723" } }

Look for a line that says:

The SAML Assertion contained the following attributes:

You have mentioned that you want to delegate the authorization to the LDAP realm. As Tim already explainer earlier: In order to do that, you need to configure attributes.principal to be the SAML Attribute that contains the value that is the user's uid in LDAP. So from all the SAML attributes that your IDP is sending and you need to determine which one has a value that corresponds to the value of the uid Attribute in LDAP.

Please do not share any SAML role mappings as these are irrelevant to the above and only complicate the discussion without adding any benefit. You have said that you want to do delegation in the LDAP realm ( == NOT in the SAML realm) , so -once the issue above is fixed- you would need to create role mappings that use information from the LDAP realm (see here for more information), and not the SAML one.


Slightly unrelated to the above discussion: Are you certain you need to delegate authorization to an LDAP realm ? It looks like that the SAML IDP uses this same LDAP to authenticate the users and it also gets their group memberships and releases this information within the SAML Assertion as the groups attribute. Why not use the value of groups attribute from SAML and SAML Role mappings to assign roles to your users instead of doing an extra call to your LDAP (by using the LDAP realm as an authorization realm ) in order to get the group membership information that you already have ?

@ikakavas Yes I'm considering value of groups attribute to do role mappings for SAML. I have followed this
https://www.elastic.co/guide/en/elastic-stack-overview/6.7/saml-role-mapping.html

I'm able to do mappings with username but not with groups.
The below works-

PUT _security/role_mapping/saml-kibana' -H 'Content-Type: application/json' -d'
{
"roles": [ "events-admin" ],
"enabled": true,
"rules": { "all": [
{ "field": { "realm.name": "saml1" } },
{ "field": { "username": "rgujral@apple.com" } }
]}
}'

But not when I try to map group for accessing saml (already mapped in IDP)

PUT _security/role_mapping/saml-kibana-group" -H 'Content-Type: application/json' -d'
{
"roles": [ "superuser" ],
"enabled": true,
"rules": { "all": [
{ "field": { "realm.name": "saml1" } },
{ "field": { "groups": "10606723" } }
] 
} 
}'

Please take the time to correctly format your posts. It greatly helps people that try to assist you. You can use the preview panel on the right to make sure your post looks fine. It would be great if you can fix that for your previous post.

Also do take the time to explain what you want to achieve, so that we can help you do that. Judging from what you said above, is it safe to assume that you don't want to use LDAP as an authorization realm anymore, and we should focus on getting your saml role mappings right ?

Finally, please do provider all the information you are asked to provide in previous answers. This will minimize the number of posts all of us have to write and eventually help you resolve your issues quickly. I Asked you above:

Did you do that ? What is this output? Can you share the logs with us ?

I'm not seeing anything that corresponds to attributes in elasticsearch logs, I'm only getting assertions and responses

I know I should get some string which shows attributes but I'm not getting. Is this because I have enabled encryption ?

No, as you can imagine we need to decrypt the assertion in order to consume it, so we get access to the attributes.

I can't understand how this happens, as we do print them in TRACE level. If you can't find them, can you at least copy paste here the part of your logs where the SAML authentication happens?

p.s. your post above is still not correctly formatted :slight_smile: Please fix that.

tail -f es-coordinating.log |grep -i "response"

[2019-06-11T10:13:15,008][TRACE][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] Received SAML Message: <?xml version="1.0" encoding="UTF-8"?><samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Destination="https://gbiobserver-events-dev.corp.apple.com:443/api/security/v1/saml" ID="A46613a3d-2c75-4ba3-895c-d98060bdf54d" InResponseTo="_5a9479cd892c6bd59520639734844407daf60d94" IssueInstant="2019-06-11T10:13:12.000Z" Version="2.0">
</samlp:Response>
[2019-06-11T10:13:15,047][TRACE][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] SAML Response: [
    Response ID: A46613a3d-2c75-4ba3-895c-d98060bdf54d
    In response to: _5a9479cd892c6bd59520639734844407daf60d94
    Response issued at:2019-06-11T10:13:12.000Z
      <saml:SubjectConfirmationData InResponseTo="_5a9479cd892c6bd59520639734844407daf60d94" NotOnOrAfter="2019-06-11T10:18:12Z" Recipient="https://gbiobserver-events-dev.corp.apple.com:443/api/security/v1/saml">
    Response ID: A5b426c59-f356-4cfc-99f8-c6c7fb08da52
    Response issued at: 2019-06-11T10:13:12.000Z
[2019-06-11T10:13:15,145][TRACE][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] SAML Assertion Subject Confirmation is in response to: _5a9479cd892c6bd59520639734844407daf60d94

You should be looking for a line that starts with The SAML Assertion contained the following attributes: . What you have shared is you looking for the string response.

tail -f es-coordinating.log |grep -i "attributes"

  <saml:AttributeStatement>
  </saml:AttributeStatement>
[2019-06-11T17:12:37,768][TRACE][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] SAML AttributeStatement has [5] attributes and [0] encrypted attributes
[2019-06-11T17:12:37,770][TRACE][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] The SAML Assertion contained the following attributes: 
[2019-06-11T17:12:37,771][DEBUG][o.e.x.s.a.s.SamlRealm    ] [es-coordinating-1] Parsed token [SamlToken{3c73616d6c703a526573706f6e73652044657374696e6174696f6e3d2268747470733a2f2f6762696f627365727665722d6576656e74732d6465762e636f7270...}] to attributes [SamlAttributes(NameId(urn:oasis:names:tc:SAML:2.0:nameid-format:persistent)=rgujral@apple.com)[A40c6a056-1c32-49e8-90b8-ae87585290f7]{[Email=[rgujral@apple.com], FirstName=[Rohit], LastName=[Gujral], ADSID=[001333-04-7c6572cc-78ce-4312-add7-43a5df78a12d], Groups=[10606723,10182173,10447632,10589740,1002775869]]}]

So I'm mapped to a group 10606723. but when I map it for saml via API, I don't get access to kibana

PUT. _security/role_mapping/saml-kibana-group" -H 'Content-Type: application/json' -d'

{

"roles": [ "superuser" ],

"enabled": true,

"rules": { "all": [

{ "field": { "realm.name": "saml1" } },

{ "field": { "Groups": "10606723" } }

]

}

}'

As you can also find in our documentation you need to map the saml attribute to the relevant user property in elasticsearch and then use that property in your role mappings. More concretely you need to add

attributes.groups: Groups

to your saml realm configuration in elasticsearch.yml and then change your role mapping rule to

{ "field": { "groups": "10606723" } }

attributes.groups: Groups or attributes.groups: groups

for the reasons I explained in my previous post

still not working
saml config-

xpack.security.authc.realms.saml1:
      type: saml
      order: 2
      idp.metadata.path: /usr/share/elasticsearch/config/saml/idp-metadata.xml
      idp.entity_id: "AppleSSO"
      sp.entity_id: "{entity_id}"
      sp.acs: "{acs}"
      sp.logout: "{logout}"
      attributes.principal: "nameid:persistent"
      attributes.groups: "Groups"
      encryption.key: /usr/share/elasticsearch/config/saml-cert/tls.key
      encryption.certificate: /usr/share/elasticsearch/config/saml-cert/tls.crt

API for mapping
PUT _security/role_mapping/saml-kibana-group" -H 'Content-Type: application/json' -d'

{

"roles": [ "superuser" ],

"enabled": true,

"rules": { "all": [

{ "field": { "realm.name": "saml1" } },

{ "field": { "groups": "10606723" } }

]

}

}'

Error on kibana page

{"message":"action [indices:data/read/search] is unauthorized for user [rgujral@apple.com]: [security_exception] action [indices:data/read/search] is unauthorized for user [rgujral@apple.com]","statusCode":403,"error":"Forbidden"}

enable the role mapping TRACE logging

PUT /_cluster/settings
{
  "transient": {
    "logger.org.elasticsearch.xpack.security.authc.support.mapper": "trace"
  }
} 

try to login again and look into (or share for us to look) your elasticsearch logs. The reason you are not getting authorized will be evident there. If you do select to share your logs, please do not use tail and grep as this will output only one line from the log entry and we need to see all of it. Grab the part of logs that is relevant to this troubleshooting and copy paste it here (using the proper formatting )

Can you also share how the relevant part to Groups within the

<saml:AttributeStatement>


</saml:AttributeStatement>

part looks like in your logs ?

2019-06-11T19:17:50,535][TRACE][o.e.x.s.a.s.SamlRealm    ] [es-coordinating-1] Constructed SAML Authentication Request: <?xml version="1.0" encoding="UTF-8"?><saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://gbiobserver-events-dev.corp.apple.com:443/api/security/v1/saml" Destination="https://idmsac-uat.corp.apple.com/IDMSWebAuth/SAMLLogin" ID="_8efa8af8bb5c6e98f124268e33fd7a4ea404fd76" IssueInstant="2019-06-11T19:17:50.534Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://gbiobserver-events-dev.corp.apple.com</saml2:Issuer>
  <saml2p:NameIDPolicy AllowCreate="false" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</saml2p:AuthnRequest>
[2019-06-11T19:20:54,444][TRACE][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] Received SAML Message: <?xml version="1.0" encoding="UTF-8"?><samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Destination="https://gbiobserver-events-dev.corp.apple.com:443/api/security/v1/saml" ID="A36bc4d95-6233-412c-be3f-4347aa19657e" InResponseTo="_7330cdc61193d9d0de5c4a749e46fac02aa639ec" IssueInstant="2019-06-11T19:20:51.000Z" Version="2.0">
      
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">AppleSSO</saml:Issuer>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
      <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
      <Reference URI="#A36bc4d95-6233-412c-be3f-4347aa19657e">
        <Transforms>
          <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        </Transforms>
        <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
        <DigestValue>Qm9Qt+QR9V/H3scLjERTLcvo1lI2hBVFoL8eJQsWhIw=</DigestValue>
      </Reference>
    </SignedInfo>
    <SignatureValue>opOEXSUQ5YLSVxAAMMJHaGoQu4rOAJ+r65+Pi6De68S24/HZ3vk5jCIwfQeHkkQbqmbFIAfweS2mxLqDkI58rKoOEMI23Jm0DBKGkXff8rdyq3fCDTBsLbfS1pRBZwEacqhPv+J3TGe8j2GxoOHcGMaAIda1VHFAR2JTa8JGsKA2IWUw5iY4kl11E8acMAQP/G1Nj5QXAQGzoDAj9YEGbTB9e1xLhYL/vlV8jODoll3tPTf0CXuO2uLhkkAU9WNSuMc5CI6hvjnraSxFbo6vEhLtUAq8h5P+hpmgg0Z5tDFfUPD2rk5eR7eVtJMYjtaMF9DB2HTbHvuHqKPX0eOuHQ==</SignatureValue>
    <KeyInfo>
      <X509Data>

MIIEBTCCAu2gAwIBAgIIKi9WN1V3WZwwDQYJKoZIhvcNAQELBQAwfTEzMDEGA1UEAwwqVGVzdCBTU08gQXV0aCBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSQwIgYDVQQLDBtJU1QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxEzARBgNVBAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMB4XDTE4MTAwMjE4MTgzMVoXDTIwMTAwMTE4MTgzMVowVzElMCMGA1UEAwwcc3Nvc2FtbHNpZ251YXQyMDE4LmFwcGxlLmNvbTEMMAoGA1UECwwDSVNUMRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJVUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANQIZ/BscAAv9f1TpUxip2vc4CJv32gsQsIvutrDnP2Qf95EYoFFAR63mjWlou5ZfICFmGpqOGYmK9zgmlQQDEe6jowMdIPsrBMnWkMBSt+5D4jYcXJ7K/YsiWjzA73+y2U3NloxqdrZKQoUgeThUFVc4N4xXsCs+virDHAn0bsITBtE/CJoYWWNJvNH+aX1IyrVBUbGqCRfhVAJgkZi2i1tjKvWX79fMLTnvlmbhnLopUOihJGqtZF9siM7Byo07XMpfyFhfXOwoTWCjesUtI2V82JcjmocCXNY5PqR5zc95SWUyxcaY3b8H22xP+W69zRRDeDF5goxisiKsJXB0VECAwEAAaOBrjCBqzAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFASMk+jPVZacU1HYHgpziddijdY5MEsGCCsGAQUFBwEBBD8wPTA7BggrBgEFBQcwAYYvaHR0cDovL29jc3AtdWF0LmNvcnAuYXBwbGUuY29tL29jc3AwMy1zc29hdXRoMDEwHQYDVR0OBBYEFAtv+2yfuAW+X4SgmZzMATjARa07MA4GA1UdDwEB/wQEAwIHgDANBgkqhkiG9w0BAQsFAAOCAQEAkrfGc/pt/GA2FXqhxj/z2AF1MEBHjOMuok2fqDLcmgidHaHn6znj+LLgbiHYX6RFZsG+dGZJpXm9t09ML6WSfcJB1IbVU4sS9cGI+11TUQD/ZJu27Fx6HkTnihkYNaSrYBAj9kcrZBwxJ1ncepbrzzAAy5j7jV3KrlOiJeKa8OkSHap1pKxB/sIfTn+bGS13CuI1z+EpwvePvLfOYuWmSB+raSEobumUvVNnQ2V0kVxLoYe9G6S4GYx/YYV4rM1EB2VX7I48HhdInK1xt8An/gHiJQcgytHpmPC2WQo31my5YIca09IelggJSvoAf0WXKf8X0Ix/fJa+awAYSWINHA==


  <samlp:Status>
            
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
        
  </samlp:Status>
      
  <saml2:EncryptedAssertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
            
    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="_cbc248db74e1ad9f736914cfacd0e52d" Type="http://www.w3.org/2001/04/xmlenc#Element">
                  
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                  
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                        
        <ds:RetrievalMethod Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey" URI="#_3c2f2bb099a66f872f898011e5cfb3e3"/>
                    
      </ds:KeyInfo>
              
    </xenc:EncryptedData>
            
    <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="_3c2f2bb099a66f872f898011e5cfb3e3">
                  
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
                  
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                        
        <ds:X509Data>
                              
          <ds:X509Certificate>MIIDJDCCAgygAwIBAgIVANlcu01fClkp8ze64igHdD/fjv7hMA0GCSqGSIb3DQEBCwUAMDQxMjAw
BgNVBAMTKUVsYXN0aWMgQ2VydGlmaWNhdGUgVG9vbCBBdXRvZ2VuZXJhdGVkIENBMB4XDTE5MDUy
MTE2MzY1NFoXDTIyMDUyNTE2MzY1NFowFDESMBAGA1UEAxMJc2FtbC1zaWduMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlFryq6Q1uKkzDyCSc9r3C0K0Bb5ljUjqwGej7fcJ1cqo+prd
g0KMK25ZPKBpZWmHVqoSBuAB4fTuvm7p7mEIQTP2WVT3vvcPlqEPtuq0/WpHuT+diuDR0T4s5zQN
tpI6dmnCp/22B/0haqtzlTsS/ahy42ZPG7v+Lrc3uOrjnmWHeGGamQEboEuH+9yPQOZ+KJz4Ko7z
IwlHJElkRwcK2ydmbekafoX8zYV0V19/TGkYDKLO7zF2hwzGV4J4p5duElHQ7pvc7VHujjOtSlHN
jUiwyW5K6ZtupFW4C7aqN9FPSrONbnPfuFLBoyLMKgAs1aGCxcvxOixTe3N8DKzkqwIDAQABo00w
SzAdBgNVHQ4EFgQUTLaa6hl5mk0pL85X+X2kEjSgPaEwHwYDVR0jBBgwFoAUfr7WTHnmUPomVWym
Qzie5YehNoEwCQYDVR0TBAIwADANBgkqhkiG9w0BAQsFAAOCAQEAMqbiEKN1WVK1FPavDJaGL9S4
mUgWnv1xbeiig58OdeE+6KgpK2wMO7WdLcITORBWvVSFHtHKlxW62mpZDSJTtBRs4vrklfmz9ehD
t8l5midnxlhhOh1l5q9xtlsQjdYI2wwRo+UGkYuLlEpyhQhh73prQvixvtfRt/fwb9R0pxCoXilf
463kLnjZNtDugFChkKvMLF2TtPLs+qNsefj2wwAfaPaOiwPJ41YAXpOhNIQJFbdcx4zrAgFn/Ahu
zcMBa0SyVzxds8gwXmgHmoBU57bn1QWF6gjW6QBQeMAigKZ96Q9TKqw3fDF5vC8F1PVL3i4qC+qm
BhwISNj3dSeNwA==</ds:X509Certificate>
                          
        </ds:X509Data>
                    
      </ds:KeyInfo>
                  
      <xenc:CipherData>
                        
        <xenc:CipherValue>F7oP0zeXm1OkL2HWdV3wlCYyyAvvVJQveylEC1MTBBEIosMEMnL0wlILf/5Ppqz6VDAyGXyvHM5syuoG9+vGxGA0tV+30gIKxz9AoSmK6l/NqoeGZznXh6wdupIwzbzClhm32Nw+FPc29aVMjFf/lSOFP6nkjrvG8Qey0GktnDgBJMs+xH4LXU472aIBzuE5/ewcziI3bU1jp9Xw8YuYT0JS9QF8wqTk4Uqc/oIscptZWggRLyTOKYij6RYzZJ+NHffFjPQUyo0Zz6TMHIy8wP2SAW6ZvZCPkKBRMt54lp4evXV3zHJQsxIRsZzDQL/sPQsqvkHcHkINPAemrBaY0Q==</xenc:CipherValue>
                    
      </xenc:CipherData>
                  
      <xenc:ReferenceList>
                        
        <xenc:DataReference URI="#_cbc248db74e1ad9f736914cfacd0e52d"/>
                    
      </xenc:ReferenceList>
              
    </xenc:EncryptedKey>
        
  </saml2:EncryptedAssertion>
  
</samlp:Response>
  [2019-06-11T19:20:54,448][TRACE][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] SAML Response: [
            Destination: https://gbiobserver-events-dev.corp.apple.com:443/api/security/v1/saml
            Response ID: A36bc4d95-6233-412c-be3f-4347aa19657e
            In response to: _7330cdc61193d9d0de5c4a749e46fac02aa639ec
            Response issued at:2019-06-11T19:20:51.000Z
            Issuer: AppleSSO
            Number of unencrypted Assertions: 0
            Number of encrypted Assertions: 1
        ]
        [2019-06-11T19:20:54,450][DEBUG][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] SAML Signature [Qm9Qt+QR9V/H3scLjERTLcvo1lI2hBVF...] matches credentials [AppleSSO] [Sun RSA public key, 2048 bits
          params: null
          modulus: 26766665811972975756178030064681965666525671008740779482145289472358532706009872341906772908796354802541928327910887557900337991967517188814137110640447127755014976000199986857323177883643803211455217207958259040250094980176958960222410339104591903530576458985087819968338399048318015843776470668255546857206540042552922539835193877850511238135036500429116803837681724051469626428193533515691353801167465657541996999685233273911677909830097796795099146360911608762894143338768536970992923790840266986220763568037821179774604216793464981910404638567691500578593423100404331557140263119968552277123080604072989048295761
          public exponent: 65537]
        [2019-06-11T19:20:54,459][TRACE][o.e.x.s.a.s.SamlAuthenticator] [es-coordinating-1] (Possibly decrypted) Assertion: <?xml version="1.0" encoding="UTF-8"?><saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="A93ede02b-2e99-437f-b619-1c1aca1e7419" IssueInstant="2019-06-11T19:20:51Z" Version="2.0">
              
          <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">AppleSSO</saml:Issuer>