nationalsecurityagency / datawave-spring-boot-starter Goto Github PK

This is needed to allow the authorization service to use a custom AllowedCallersFilter to permit calls to the oauth operations from entities not on the allowedCallers list. These operations either have their own form of security (/v2/oauth/authorize, /v2/oauth/token) or are meant to be called by all users (/v2/oauth/user, /v2/oauth/users) to get information about a certificate or token.

Currently, the collection retrieved by ProxiedUserDetails.getProxiedUsers (which are all users) has the final caller as the first entry followed by the entities in the call chain in the order that they happened. This creates some minor complexity in finding the primaryUser and in explaining this order to others.

Modify the places where ProxiedUserDetails iws created such that the proxied entities are first (already in chronological order) and the final caller is last ..... making it also in chronological order

ProxiedUserDetails currently maintains the list of users as a LinkedHashSet which hides any duplcate users or call chain cycles from our logs and monitoring. Change the LinkedHashSet to an ArrayList and verify that our internal security mechanisms function correctly.

When there are no entries in X-ProxiedEntitiesChain, ProxiedEntityX509Filter currently adds the caller (cert or trusted header) to the list of proxiedUsers. This appears to be unnecessary and is currently being compensated for by using a LinkedHashSet in ProxiedUserDetails. Here are the three WebSecurityConfigurerAdapters that we use:

not remoteauth profile - JWTAuthenticationFilter/JWTAuthenticationProvider decode the Authorization Bearer token (JWT) and use the contained DatawaveUsers

JWTSecurityConfigurer sets up:

filters:

• AllowedCallersFilter (if a cert provided and enforceAllowedCallers=true, reject if not in list of allowedCallers)
• X509AuthenticationFilter (spring)
• JWTAuthenticationFilter (get JWT token and create a JWTPreauthToken which gets used to in the JWTAuthenticationProvider)

authenticationProviders:

• JWTAuthenticationProvider supports JWTPreauthToken

remoteauth profile - Either JWT token (see above) or RemoteAuthorizationServiceUserDetailsService sends both the caller and proxiedEntities to the authorization service.

RemoteAuthServiceSecurityConfigurer sets up:

filters:

• AllowedCallersFilter (if a cert provided and enforceAllowedCallers=true, reject if not in list of allowedCallers)
• X509AuthenticationFilter (spring)
• JWTAuthenticationFilter (get JWT token and create a JWTPreauthToken which gets used to in the JWTAuthenticationProvider)
• ProxiedEntityX509Filter (creates a ProxiedEntityPreauthPrincipal which is then used in RemoteAuthorizationServiceUserDetailsService to call the authorization service with X-ProxiedEntitiesChain of the caller + proxiedUsers

authenticationProviders:

• JWTAuthenticationProvider supports JWTPreauthToken
• PreAuthenticatedAuthenticationProvider -> RemoteAuthorizationServiceUserDetailsService implements RemoteAuthorizationServiceUserDetailsService supports PreAuthenticatedAuthenticationToken

authorization service - ProxiedEntityUserDetailsService (authorization service) can be modified to add both the caller and proxiedUsers and then the authorization service can ignore the caller in the authorize and whoami operations and use the caller and proxiedUsers in the oauth calls.

AuthorizationSecurityConfigurer sets up:

filters:

• AllowedCallersFilter (if a cert provided and enforceAllowedCallers=true, reject if not in list of allowedCallers)
• X509AuthenticationFilter (spring)
• JWTAuthenticationFilter (get JWT token and authenticates via JWTAuthenticationProvider)
• ProxiedEntityX509Filter (creates a ProxiedEntityPreauthPrincipal which is then used in AuthenticationUserDetailsService to use the datawaveUsersService to lookup the users (previously proxiedUsers, soon caller + proxiedUsers)

authenticationProviders:

• JWTAuthenticationProvider supports JWTPreauthToken
• PreAuthenticatedAuthenticationProvider -> ProxiedEntityUserDetailsService implements AuthenticationUserDetailsService supports PreAuthenticatedAuthenticationToken

When the ProxiedEntityX509Filter is in the filter chain, the JWTAuthenticationFilter is configured to be run first.

The logic in ProxiedEntityX509Filter.principalChanged, specifically currentAuthentication.getCredentials() instanceof SubjectIssuerDNPair (credentials are an empty String when I debugged) ensure that false is always returned. When I fixed that logic, I saw that if both a JWT and either a client cert or trusted headers were provided with different principals, then a principal change would be detected and the client cert or trusted headers would be used.

To ensure that a provided JWT is used (the intent of putting the JWTAuthorizationFilter first), we need to set setCheckForPrincipalChanges(false) instead of true.