Forum Discussion
NimbostratusF5 APM as SP
It depends on how the application needs to receive them. You could inject the values into a header, form fill them, or use Kerberos as examples.
After the SAML Auth agent in the policy you'll have some session variables like:
session.saml.last.nameIDValue (This is the subject NameID)
session.saml.last.attr.name.myattributename (This will be whatever your attribute is named in your ADFS implementation)
You could use those session variables or you use a Variable Assign agent to move them into something else, such as session.logon.last.username or session.sso.token.last.username.
I'd suggest header insert if you have an option as it is simple to build into an application. You can do it with an iRule or a Per Request Policy. In the Per Request Policy insertion method you can leverage the session variable by calling %{session.saml.last.nameIDValue} as the value you're inserting into the header. Then just have your application configured to read that out of the header.
Sorry, @Anu Momin, I was commenting on the original question, not your comment, so my answer may not have made sense for your scenario.
A couple things to consider for your scenario...
I would use caution proceeding without enforcing a signed assertion (the "Want Signed Assertion" value). Without that someone may be able to forge an assertion and pretend to be another user.
One possible thing to consider for your situation with the assertion validation issue is that when importing the XML for the external IdP connector it may not have properly imported or attached the ADFS signing certificate. You could go into the external IdP connector and check the "Security Settings" section and see if the IdP Assertion Verification Certificate is selected there.
Regarding the backend auth, it sounds like you're on the right track and moving towards getting Splunk to use SAML auth, since you won't be able to just form fill a logon page that does LDAP on the backend since you don't get the password from ADFS.
