[BUG] Are ldaptive and the Pattern classes needed as part of SAFE_CLASSES list in Base64Helper?

[parasjain1]

What is the bug?
Why are ldaptive classes (LdapEntry, SearchEntry, AbstractLdapBean, LdapAttribute), Pattern class part of the SAFE_CLASSES list in Base64Helper? (source code).

Additional Context

While working on #2780 for a faster serialization protocol in Security Plugin, I encountered a doubt around whether the above mentioned classes are needed as part of SAFE_CLASSES list in Base64Helper?

I tracked all usages of Base64Helper::serializeObject and Base64Helper::deserializeObject and found only the following classes to be directly serialized/deserialized in security plugin -

• String
• UnmodifiableMap (for DLS queries, Masked Fields, FLS Fields)
• SourceFieldsContext
• User
• LdapUser
• InjectedUser
• InetSocketAddress

To track nested usages of ldaptive classes and the Pattern class for the above classes, found that they are only used with the LdapUser (which extends from User). Below are few observations that I noted -

• The LdapEntry userEntry field of LdapUser is transient and not serialized. The comment on User::getUserEntry specifies this clearly, deserialized LdapUser will have null value for userEntry.

• LdapAuthenticationBackend has the functionality to construct LdapEntry and LdapAttribute for the user and takes care of populating the user attributes map here.

• LdapAttribute too is not involved in serialization as the value of LdapAttribute::getName() is used to populate the User::attributes map (source code)

• I removed the all of the mentioned classes from SAFE_CLASSES list and could (de)serialize LdapUser without any issues.

The above observations lead me to the conclusion that these classes are NOT needed to be listed as SAFE_CLASSES. Starting this issue to understand the reasoning behind the presence of these classes in SAFE_CLASSES, in case they indeed are to be present, otherwise, get a confirmation on the above pointers and conclude that their removal from SAFE_CLASSES will not break anything.

[parasjain1]

Here are the changes that remove the above mentioned classes from SAFE_CLASSES along with a couple of additional tests for Base64Helper.
main...parasjain1:opensearch-security:parasjaz-safe-class-removal

[nibix]

@parasjain1

The above observations lead me to the conclusion that these classes are NOT needed to be listed as SAFE_CLASSES.

I am sharing this conclusion, it looks indeed like these classes are not needed there :)