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.
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
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]]
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"
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.
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.
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
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.
thank you ikakavas
i thought SubjectConfirmationData is destination parameter. so can you send me a sample what the destination parameter looks like.
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 )
i can not find the parameter in the SAML response message , so why it can work in version 6.3.1.
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.
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?
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 )
1 Like
thank you very much
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" ] }
}
}
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.
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$"
That field should be "metadata.saml(Email)"
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"