Luke Taylor (Migrated from SEC-1492) said:
Currently, AuthenticationProvider/UserDetailsService implementations do not have a consistent way of creating authorities (case-conversions, role prefixes, mapping to rights etc). It would make sense to inject an Attributes2GrantedAuthoritiesMapper instance which can be used to provide full control over the authority values. This can also be used to implement RBAC style rights, performing mapping of assigned roles to permissions recognised by the application.
Luke Taylor said:
I think it might make sense here to consider having two mapping layers. One at DAO level (used, for example in the UserDetailsService implementations), which will convert the string attributes, and another at the authentication layer, so that the authorities which are stored in the Authentication object can be manipulated, rather than just being copied directly from the loaded ones.
I've added a GrantedAuthoritiesMapper interface which can be injected into AuthenticationProvider instances and provides a mapping layer between the authorities loaded by the DAO (e.g. UserDetailsService or LdapAuthoritiesPopulator) and those which are returned by the Authentication object. This allows the original values to be retained (e.g. for use in user CRUD operations) while using the mapped values (e.g. RBAC-style application permissions) for runtime access decisions.
I think this should be sufficient and won't be introducing any additional mapping at the Dao layer for now.
Frank Scheffler said:
In my opinion, the problem with the new GrantedAuthoritiesMapper is, however, that the mapper only receives a collection of GrantedAuthorities as a source. What, if it needs to find an externally authenticated user (e.g. LDAP) within an internal storage (e.g. JDBC) to look up its groups and roles? I know, that there exists a UserDetailsServiceLdapAuthoritiesPopulator, but that is only for LDAP not for CAS, and the like. In our JDBC storage we have both internal users, which may be directly authenticated, and external users only used for role mapping.
This issue is related to #1730
This issue supersedes #1432