An often asked question when configuring SAML is how do you ensure users can access their knowledge objects and saved searches that were created before migrating to SAML? Do you need to a script that migrates the users’ knowledge objects? As always is the case, the answer isn’t simple but it depends on the authentication mechanism prior to SAML.
When moving from LDAP to SAML, if the same LDAP server is configured as the backend authentication database on the Identity Provider(Adfs, Okta, Ping…), then the users would be the same and the groups they belong to would be the same.
Then moving from LDAP to SAML and retaining the previously created knowledge objects is straightforward and can be achieved in a couple of steps starting with configuring the authentication type on Splunk as SAML.
Step 2 is to ensure the username is the same as before using the NameIdFormat setting in Splunk(and on the Identity Provider).
Lastly – manually edit authentication.conf and copy roleMap_<LDAPstrategy> to roleMap_SAML(or rolemap_SAML in versions prior to 6.5).
And voila! Once the user logs in, everything would work as before.
Well, why doesn’t this work when migrating other authentication mechanisms to SAML. Well, it turns out there is something more to be done when switching from Spunk’s local authentication mechanism to SAML.
We need to either ensure – a) the usernames are the same between SAML(which now is getting this information from LDAP configured on the IdP) and what was in Spunk local authentication. b) Ensuring the role mapping for the groups that are returned is consistent and results in the same spunk roles for the same user. c) remove the local users especially if the username is the same but the roles returned don’t match.