Splunk SAML authentication - Data Confidentiality issue

[ashutosh2020]

Hi,

I am using SAML Authentication with an IDP for SSO. Everything works perfect unless we noticed an issue. The users created by our Identity Provider receives a User Level access. The SSO receives users from our Active Directory. The issue arises when the AD team can create any random user and add him to our group and immediately the user receives User Level access to splunk.

The challenge occurs when the Splunk Admin can not control the user created through SAML. Splunk Admin can not delete / change user role of the SAML users. Splunk Admin can make changes to the users created in Splunk Native Authentication as always.

If someone from AD team decides to some mischievous activity, he can create a user and get a direct access to Splunk. There is no 'check' at the splunk side if someone is authorized to access my data or not. If a user gets created under Admin in the AD, he can be dangerous.

Moreover, if Splunk Admin wants to assign a new role to a SAML user, he will not be able to do so. In such case we are completely dependent on the AD team. This becomes an operational issue, as well as it opens gate to data confidentiality.

Please guide me on how to get over this and solve the issue. I might be doing something in an incorrect way and facing the case.

Following are few more points to note.
1. The way we are integration with SAML is incorrect?
2. Can we control user authorization on the splunk side?
3. If we happen to create a user role with lease possible capabilities and assign every new user to that Role, what capabilities the users will have. Even after this, splunk admin is not able to change the user capabilities.

Please help me with the above.

[suarezry]

The way we are integration with SAML is incorrect?

Did you setup role mapping with your SAML integration? Your Identity Provider passes an attribute that contains the splunk role the user should belong to:
https://docs.splunk.com/Documentation/Splunk/7.2.4/Security/Mapgroupstoroles

Can we control user authorization on the splunk side?

Yes, look at the authentication.conf spec:
https://docs.splunk.com/Documentation/Splunk/7.2.4/Admin/Authenticationconf

defaultRoleIfMissing = <splunk role>
* OPTIONAL
* If the IDP does not return any AD groups or splunk roles as a part of the
  assertion, we will use this value if provided.

Create a role with no permissions as the default role.

[nickhills]

How does this help if the IDP admin "accidentally' adds a wrong user to the 'admin_group' mapped to the 'admin_role'

[nickhills]

This is not a limitation of Splunk, but a design/implementation feature of SAML.

When you set up SAML you are essentially saying 'I trust this authentication provider to authenticate and authorise users on my system'

If you do not trust the the IDP (or the administrators who look after it) you should probably use a different authentication mechanism.

[ashutosh2020]

ok, Can we atleast have a way where the SAML does not create users on it's own?

[suarezry]

When you set up SAML you are essentially saying 'I trust this authentication provider to authenticate and authorise users on my system'

This is incorrect. The role of the Authentication provider is to verify that the user is who they say they are. The role of the Service Provider (Splunk) is to authorize who has access to this system.

[nickhills]

I don't intend to argue semantics, but the implication of mapping groups to roles in Splunk (ie "set[ting] up SAML"), means that that if the SAML provider tells you 'user x' is in the 'splunk_admin' user group, and Splunk has that group mapped to the 'admin_role', then the authorisation for those users is affected by group membership in the IDP - Yes it is your choice to trust it (or not) but in a real world, effectively the IDP admin can directly affect who is authorised for a given role.

In the context of the way SAML is implemented in Splunk using group -> role mapping you ARE trusting the "authentication provider to authenticate and (control) authorise(d) users on [your] system"

[suarezry]

Ok, I guess we are getting into a semantics argument but I feel it's an important distinction. SAML is based on federations, a trusted relationship between the Identity Provider and the Service Provider. If the Identity Provider is no longer trusted then that trust is revoked by the Service Provider. The point I'm clarifying is that it's the Service Provider makes the authorization decisions, not the Identity Provider.

[nickhills]

If you want your Splunk admin team to review/gate access to Splunk resources, the simplest way is to use the Splunk local authentication system.

In all other cases where you are using an external identity system there is always the risk that a user with root/domain/enterprise admin rights could make an error in configuration, and grant a permission to a user in error.

Many organisations which are using some form of SSO/SAML or shared identity systems have robust controls over user account creation, and can even use multi-step workflow to ensure that access is not only granted, but reviewed prior to doing so.

I could be provocative, and mention that your Splunk amins are human too, and just a likely to make an error when creating users and granting access, but you have to trust that your privileged users are skilled and diligent enough to not 'likely' make mistakes, and/or Implement review processes to catch any misconfigurations, should they occur.

This is not really a Splunk problem, and is something to take to your InfoSec team and ask the bigger question about your enterprise access management policies.

[sduff_splunk]

You can either use AD/SAML integration, where by Splunk user accounts are managed by the team managing AD/SAML, or you can use local Splunk accounts on the search head.

At some point, you need to trust the AD admins. If the Splunk Admin feels that the AD team can't be trusted, then they would be able to disable SAML/AD access and only rely on local accounts.

Splunk's _internal logging would track all user activity regardless.