Skip to content

Conversation

slobodanadamovic
Copy link
Contributor

@slobodanadamovic slobodanadamovic commented Aug 19, 2025

This PR is twofold:

  • it adds a new private_attributes setting to the SAML realm, and
  • introduces extension point that allows providing a custom SamlAuthenticateResponseHandler

The private_attributes setting can be used to define which SAML attributes should be treated as private. This implies that these attributes will not be logged or returned as part of user's metadata when populate_user_metadata is set to true.

This PR is twofold:
- it adds a new `secure_attributes` setting to the SAML realm, and
- introduces extension point that allows providing a custom
 `SamlAuthenticateResponseHandler`

The `secure_attributes` setting can be used to define which SAML attributes
should be treated as secure. This implies that these attributes should not
be logged, or returned as part of user's metadata when
`populate_user_metadata` is set to `true`.
@slobodanadamovic slobodanadamovic self-assigned this Aug 19, 2025
@slobodanadamovic slobodanadamovic added >enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) Team:Security Meta label for security team labels Aug 19, 2025
@elasticsearchmachine
Copy link
Collaborator

Hi @slobodanadamovic, I've created a changelog YAML for you.

*/
public static final Function<String, Setting.AffixSetting<List<String>>> SECURE_ATTRIBUTES = (type) -> Setting.affixKeySetting(
RealmSettings.realmSettingPrefix(type),
"secure_attributes",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is secure the right word? It implies that other attributes are "insecure".
Maybe private or confidential?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the callout. I was on the fence between secure, private and secret. Went with secure as it seemed like a better fit (at least implementation wise). I'm okay with private. Technically, the main goal is to allow hiding certain attributes and treating them as private only.

@slobodanadamovic slobodanadamovic marked this pull request as ready for review August 20, 2025 08:56
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-security (Team:Security)

@slobodanadamovic slobodanadamovic changed the title Allow cofiguring SAML secure attributes Allow configuring SAML secure attributes Aug 20, 2025
@elasticsearchmachine elasticsearchmachine added the serverless-linked Added by automation, don't add manually label Aug 20, 2025
@slobodanadamovic slobodanadamovic changed the title Allow configuring SAML secure attributes Allow configuring SAML private attributes Aug 20, 2025
@tvernum tvernum self-requested a review August 21, 2025 05:15
@slobodanadamovic slobodanadamovic merged commit 0c6100d into elastic:main Aug 22, 2025
41 checks passed
pabloem pushed a commit to pabloem/elasticsearch that referenced this pull request Aug 22, 2025
This PR is twofold:
- adds a new `private_attributes` setting to the SAML realm, and
- introduces extension point that allows providing a custom `SamlAuthenticateResponseHandler`

The `private_attributes` setting can be used to define which SAML 
attributes should be treated as private. This implies that these 
attributes will not be logged or returned as part of user's metadata 
when `populate_user_metadata` is set to `true`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Security/Authentication Logging in, Usernames/passwords, Realms (Native/LDAP/AD/SAML/PKI/etc) serverless-linked Added by automation, don't add manually Team:Security Meta label for security team v9.2.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants