Uploaded image for project: 'SX Spring Security Extension'
  1. SX Spring Security Extension
  2. SES-69

Data returned from SAMLUserDetailsService and UserDetailsService put into different fields of the Authentication object

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: saml-1.0.0.RC1
    • Fix Version/s: saml-1.0.0.RC1
    • Component/s: saml
    • Labels:
      None

      Description

      We are using SAML for our production environment and username & password authentication for development. In production we an implementation of SAMLUserDetailsService to get information about the user and in development we use the corresponding functionality by implementing UserDetailsService (both return the same kind of object with information about the user). However the result returned from these two services is put in to different fields of the Authentication object depending on the authentication scheme used. When using SAML the object is put in to the details field and when using username & password authentication it is put into the principal field.

      This makes it hard to have the same code to get at the object returned from the SAMLUserDetailsService/UserDetailsService as we have to know which authentication scheme was used. My personal opinion is that the SAML module should behave as the username & password authentication and put the data in the principal field.

        Activity

        Hide
        gwa GWA added a comment -

        It's true this is a little odd compare to all other authentication provider I know

        Anyway, in the SAMLAuthenticationProvider there's a comment on the getPrincipal method that insist that the method can be override

        In your project you can declare a provider like this one instead of the vanilla SAMLAuthenticationProvider. This will do exactly what you need.

        public class PersonalSamlAuthenticationProvider extends SAMLAuthenticationProvider{

        /**

        • @param consumer
          */
          public PersonalSamlAuthenticationProvider(WebSSOProfileConsumer consumer) { super(consumer); }

        /* (non-Javadoc)

        • @see org.springframework.security.saml.SAMLAuthenticationProvider#getPrincipal(org.springframework.security.saml.SAMLCredential, java.lang.Object)
          */
          @Override
          protected Object getPrincipal(SAMLCredential credential, Object userDetail)
          Unknown macro: { if (userDetail!=null){ return userDetail; } return super.getPrincipal(credential, userDetail); }

          }

        Show
        gwa GWA added a comment - It's true this is a little odd compare to all other authentication provider I know Anyway, in the SAMLAuthenticationProvider there's a comment on the getPrincipal method that insist that the method can be override In your project you can declare a provider like this one instead of the vanilla SAMLAuthenticationProvider. This will do exactly what you need. public class PersonalSamlAuthenticationProvider extends SAMLAuthenticationProvider{ /** @param consumer */ public PersonalSamlAuthenticationProvider(WebSSOProfileConsumer consumer) { super(consumer); } /* (non-Javadoc) @see org.springframework.security.saml.SAMLAuthenticationProvider#getPrincipal(org.springframework.security.saml.SAMLCredential, java.lang.Object) */ @Override protected Object getPrincipal(SAMLCredential credential, Object userDetail) Unknown macro: { if (userDetail!=null){ return userDetail; } return super.getPrincipal(credential, userDetail); } }
        Hide
        mel Mandus Elfving added a comment -

        I am aware that you can always override the authentication provider, but it seems a bit odd that the SAML extension behaves in a way that isn't consistent with the other authentication methods.Therefore I think it should be considered to change the SAML extension to behave as the others do.

        Show
        mel Mandus Elfving added a comment - I am aware that you can always override the authentication provider, but it seems a bit odd that the SAML extension behaves in a way that isn't consistent with the other authentication methods.Therefore I think it should be considered to change the SAML extension to behave as the others do.
        Hide
        vsch Vladimir Schäfer added a comment -

        Behavior of principal field is now identical to AbstractUserDetailsAuthenticationProvider. By default userDetail object is now put to the principal field of the Authentication object. Previous behavior can be enabled by setting property forcePrincipalAsString to true on the SAMLAuthenticationProvider.

        Show
        vsch Vladimir Schäfer added a comment - Behavior of principal field is now identical to AbstractUserDetailsAuthenticationProvider. By default userDetail object is now put to the principal field of the Authentication object. Previous behavior can be enabled by setting property forcePrincipalAsString to true on the SAMLAuthenticationProvider.

          People

          • Assignee:
            vsch Vladimir Schäfer
            Reporter:
            mel Mandus Elfving
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development