We are trying to have our users authenticated on our idP running simpleSAMLphp before they can have access to Splunk Apps.
The authentication part is working fine, as our users get redirected and authenticated successfully on our idP, before being redirected back to Splunk for accessing the Apps.
At this point, we end up with an error message:
No valid Splunk role found in the local mapping or assertion
Our users belong to a group named "role" on the idP, but for an unknown reason, it seems that this attribute is not taken into account by Splunk.
Is there a specific format that the idP needs to use in order to pass on the attributes to Splunk?
Is there simplesamlphp config file examples available?
Any help would be much appreciated,
On your Splunk Search Head you must configure the SAML roles to map to Splunk roles.
Click "Settings" - "Access controls" - "Authentication method" - "SAML settings"
In the upper right corner, click the "New Group" button.
Given the information you provided, name your new group "admin" and then assign it the Splunk role of "admin"
Make sure the cookies a cleared before retest.
I didn't look at the SAML response close enough to determine if you need to remap an attribute. Provided everything else is good this should work.
Currently, only Ping Identity is certified as an IDP for Splunk SAML. Unfortunately, the SAML standard leaves room for interpretation when it comes to implementing attribute calls, which is why you may see your issues.
I am not exactly sure what simpleSAMLphp is, but I think your users must be configured to be part of a group that is returned to Splunk as the 'role' attribute. You also need realName and mail attributes.
You may or may not be able to get this to work. I would suggest you create a P4 case with Splunk support and make your desire to have your IdP supported known.
Thanks for that, much appreciated. Indeed attributes role, realName and mail are part of the user attributes on the idP.
And those are sent back to Splunk as part of the SAMLResponse parameter.
Here a decode of the SAMLResponse parameter sent from the idP to Splunk :
Could it be because of the Attribute format used in our implementation ? : NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
Thanks for the support
<saml:NameID SPNameQualifier="entityid" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:email">email@example.com</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData NotOnOrAfter="2016-02-10T10:22:52Z" Recipient="http://splunk.exemple.org:8000/saml/acs" InResponseTo="entityid.1.1EB5E003-8144-49C4-AEB5-5AC9EB9BFF3"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2016-02-10T10:17:22Z" NotOnOrAfter="2016-02-10T10:22:52Z"> <saml:AudienceRestriction><saml:Audience>entityid</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2016-02-10T10:17:52Z" SessionNotOnOrAfter="2016-02-10T18:17:52Z" SessionIndex="_b3313f75da4f84105e36e74242315fbfeca32d442c"> <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement> <saml:AttributeStatement> <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">firstname.lastname@example.org</saml:AttributeValue></saml:Attribute> <saml:Attribute Name="realName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"><saml:AttributeValue xsi:type="xs:string">John Doe</saml:AttributeValue></saml:Attribute> <saml:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"><saml:AttributeValue xsi:type="xs:string">admin</saml:AttributeValue></saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </samlp:Response>
For Splunk version 6.3, we require the 'role' attribute to be in the DN format - something like "CN=admin, OU=splunk, OU=com" or atleast one key=value pair like "CN=admin".
But the saml response above will work with Splunk 6.4 where this restriction has been removed.