Elasticsearch SAML integration while using HTTP-Redirect

talon · July 19, 2018, 2:31am

ok
As the idp is provided by other team in our company ,so it is hard to reconfigure the idp.
other question
whether it is possible the issue's root cause is "Elasticsearch can't validate the digital signature of the SAML response" and that means the cert provided by idp is not right.

TimV · July 19, 2018, 2:57am

This is the error you reported.

It is caused by your IdP not sending a Destination attribute in the SAML message.
That is not supported by any Elasticsearch version prior to 6.3.1

talon · July 20, 2018, 3:35am

HI Tim
the issue disappeared in 6.3.1, thank you
and i faced another, can you tell me how to config attributes
below is my configuration.
attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
attribute_patterns.principal: "^([^@]+)@Honeywell.com$"

and the error from elastic is
SAML Attribute [http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress] with pattern [^([^@]+)@Honeywell.com$] for [attributes.principal] not found in [Email=[Dengfeng.Nguyen@Honeywell.com], First Name=[Dengfeng], Last Name=[Ruan]]

ikakavas · July 20, 2018, 4:27am

Again, the SAML Guide has all the information you need

This specific error is because you are have configured

attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

but your IDP is configured to send SAML attributes with short names instead of the claim full name, so the email SAML attribute has a name of Email

attributes.principal: "Email"

talon · July 22, 2018, 7:09am

HI Ikakavas
I want to confirm if my understanding about [https://github.com/elastic/elasticsearch/pull/31175](http://version 6.3.1) is rignt.

my understanding is in version 6.3.1 validate the Destination element of an incoming SAML Response if the SAML Response is signed. no need to validate it when the response is unsigned.

in those version prior to version 6.3.1: validate the Destination element of an incoming SAML Response on matter the SAML Response is signed or unsigne.

so my issue in Version 6.2.4
[2018-07-19T00:14:16,276][WARN ][o.e.x.s.a.AuthenticationService] [logging-dev03] Authentication to realm saml3 failed - Provided SAML response is not valid for realm saml/saml3 (Caused by ElasticsearchSecurityException[SAML response yXAxKpCT8ZUdHQ8qZREyADXJSB- is for destination null but this realm uses https://sent2-kibana-dev.dsentience.net:443/api/security/v1/saml])

the root cause is SAML response IDP do not contain the destination parameter.

so if i want to use version 6.2.4 i just need reconfigue idp and let the idp send a Destination parameter no matter the response in signed or not.

ikakavas · July 23, 2018, 9:45am

Correct. This bug was fixed after 6.2.4 was released and 6.2.4 is the latest 6.2.x we have released so the fixed behavior is only available in > 6.3.1.

For 6.2.4 the only mitigation is to do as you mention

so if i want to use version 6.2.4 i just need reconfigue idp and let the idp send a Destination parameter no matter the response in signed or not.

talon · July 24, 2018, 5:48am

HI ikakavas
I have checked the idp response message , the message is signed and contain the information of destination parameter, show as below.

so i am very confused , from my understand even in version 6.2.4, as long as the saml response from idp contain a destination parameter, it will not have the issue like this
[2018-07-19T00:14:16,276][WARN ][o.e.x.s.a.AuthenticationService] [logging-dev03] Authentication to realm saml3 failed - Provided SAML response is not valid for realm saml/saml3 (Caused by ElasticsearchSecurityException[SAML response yXAxKpCT8ZUdHQ8qZREyADXJSB- is for destination null but this realm uses https://sent2-kibana-dev.dsentience.net:443/api/security/v1/saml])

besides i can not find the source code of x-pack(version 6.2.4), can you tell me how to download it.

talon

ikakavas · July 24, 2018, 6:05am

Please don't use screenshots. They are hard to read and cannot be searched. You can easily copy the actual text by using the </> buttons.

The part of the screenshot you are sharing doesn't show that the Destination parameter of the SAML Response is present. You are showing part of the SAML Assertion that is included in the SAML Response but the Destination parameter would be at the beginning of the XML document as an attribute of the <saml:Response> element. The Recipient attribute of <SubjectConfirmationData> is not what this issue is about.

We've opened up X-Pack in 6.3 and what you're looking for is part of the private x-pack-elasticsearch repository (applicable to pre 6.3) which is not available.

talon · July 24, 2018, 6:08am

thank you ikakavas

i thought SubjectConfirmationData is destination parameter. so can you send me a sample what the destination parameter looks like.

ikakavas · July 24, 2018, 6:28am

This is part of the standard. Look at line 1477 in https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf.

It is an attribute with name Destination in the <Response> element. See for instance the example from wikipedia:

<samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_2"
    InResponseTo="identifier_1"
    Version="2.0"
    IssueInstant="2004-12-05T09:22:05Z"
    Destination="https://sp.example.com/SAML2/SSO/POST">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    ...
    ...

For you, the Destination value should be the same as the Recipient of SubjectConfirmationData, and that is the AssertionConsumingService URL for the Service Provider (https://sent2-kibana-dev.dsentience.net:443/api/security/v1/saml )

talon · July 24, 2018, 6:34am

i can not find the parameter in the SAML response message , so why it can work in version 6.3.1.

ikakavas · July 24, 2018, 6:42am

As we have mentioned above in this thread and in the PR that solves this issue that you referenced earlier, the behavior of our Service Provider in 6.2.4 is wrong. It expects a Destination parameter even when the SAML Response is not signed.

In 6.3.1, we have corrected this behavior according to the spec and we only expect and attempt to validate the Destination only if the SAML Response is signed.

If this doesn't answer your question can you please rephrase it ? I am not sure what needs clarification here.

talon · July 24, 2018, 6:46am

ok i understand
so the only explanation is the response from idp is unsigned,
but the idp team tell me it's signed.
can you tell me how to confirm whether a response is signed or not?

ikakavas · July 24, 2018, 6:59am

I never said that. The only explanation for what ?

Are you certain they have configured the idp to sign the SAML Response? Because from the screenshot you have attached here, it looks like the SAML Assertion is signed. This is a different thing .

You would be able to see a <ds:Signature> element that has a <ds:Reference> child element that points to the ID of the <samlp:Response> element i.e.

<samlp:Response ID=xxxxxxxxxxx ........ >
   <ds:Signature>.....
        <ds:Reference URI="#xxxxxxxxxxx">
  ....

See also here for examples of SAML messages with combination of signed Responses and Assertions to get an idea.

I would focus on getting the idp team to understand that you want your IDP to sign SAML Responses ( not just the SAML Assertions )

talon · July 24, 2018, 7:09am

thank you very much

talon · July 25, 2018, 2:11pm

HI ikakavas
i have some question about role mapping.

As our idp team do not supply the user's group message in the SAML attributes, can i create group in ELK? and how to ?
The SAML attributes only have Email First Name and Last Name,
AS i don't know the username, can i use Email name as the field?
i have tried
curl -X POST "https://XXXXXX:9200/_xpack/security/role_mapping/mapping" -H 'Content-Type: application/json' -d'
{
"roles": [ "user", "superuser" ],
"enabled": true,
"rules": {
"field" : { "Email" : [ "XXXX@XXXX.com" ] }
}
}

ikakavas · July 25, 2018, 9:23pm

No. There is no notion of a shadow user in Elasticsearch. That is there will not be a persistent user entry in Elasticsearch for the users that authenticate via the SAML realm, so you cannot assign them groups in Elasticsearch.

Reagrding 2. The answer lies - again - in the guide

Not directly - see below

It's always helpful to tell us what happened after you tried. If it didn't work, how did it fail ?

You have two options to use Email for role mapping

User metadata. Email can then be used as saml(Email) in role mappings
Extracting username from email - our guide has this exact example - and using this in the role mappings.

Once again, please do read through our guide, it will be greatly beneficial for your understanding and will make realm configuration much easier for you.

talon · July 26, 2018, 3:49am

HI ikakavas
i tried "Email can then be used as saml(Email) in role mappings"
curl -X PUT "https://X.X.X.X:9200/_xpack/security/role_mapping/mapping" -H 'Content-Type: application/json' -d'
{
"roles": [ "superuser" ],
"enabled": true,
"rules": { "all": [
{ "field": { "realm.name": "saml3" } },
{ "field": { "saml(Email)": "Dengfeng.Nguyen@Honeywell.com" } }
] }
}

but when i login ,i don't have access to perform any actions or access any data.

the configuration in Elasticsearch.yml is
xpack.security.authc.realms.saml3:
.....
attributes.principal: "Email"
attribute_patterns.principal: "^([^@]+)@Honeywell.com$"

TimV · July 26, 2018, 4:26am

That field should be "metadata.saml(Email)"

talon · July 26, 2018, 6:14am

HI TimV
I can access after i change the field from saml(Email) to metadata.saml(Email).
and if i want to use mapping files what it should be ?
superuser:
- "metadata.saml(Email)=Dengfeng.Nguyen@Honeywell.com"
user:
- "metadata.saml(Email)=Dengfeng.Nguyen@Honeywell.com"