Robin Bramley (Migrated from SEC-931) said:
The getPrincipal method currently returns the identityUrl (which follows the method description from the Authentication interface quite literally “The identity of the principal being authenticated. This is usually a username.”), whereas other authentication providers will typically set the principal to the UserDetails object.
The AbstractUserDetailsAuthenticationProvider determines how to set the principal by the forcePrincipalAsString boolean (defaulted to false) – however note that the CasAuthenticationToken also provides a separate getUserDetails method.
Proposed fix is to provide a forcePrincipalAsString option (default set to true for backwards compatibility) in the OpenIDAuthenticationProvider with changes to the HttpSecurityBeanDefinitionParser so the provider can easily be set to use UserDetails instead of a string.
Patch to follow shortly.
Matthias Quasthoff said:
We think this issue is related to SEC-935 , as in order to obtain user information from an OpenID provider, this info should be stored in the principal object. Feel free to see our patch submitted to SEC-935
Luke Taylor said:
I think we should look at making this the default in 2.1 and also how it can be combined with the attribute exchange mechanism raised in SEC-935. At the moment the getPrincipal() method on OpenIDAuthenticationToken just returns the identityUrl and the class already has a getIdentityUrl method.
I've already changed the provider to return the UserDetails as the OpenID principal, as part of SEC-935.