Details

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

      Description

      Hi Ray,

      Thank you for your kind words. It's also nice to hear about Teradata using the module.

      The last time I was updating the token population I was trying to maintain backwards compatibility and that's the reason why NameID is used as the default principal in the Authentication object. The getPrincipal method in the SAMLAuthenticationProvider can currently be overriden to use userDetails as the default principal value. I wouldn't say it's a bug, but as you're at least second or third person who finds this to be a problem I think it's time to change it - sooner better than later.

      Could you please open a Jira issue at https://jira.springsource.org/browse/SES? I'll try to get to it sometime this or next week.

      Best,
      Vladimír

      ------------------------------------------------------------------------------------------------------------------------------------------------------------------------

      Hello Vladimir,

      First of all, thank you for writing the SAML Spring Security Extension. It is great work!

      I am a developer at Teradata and I added your code so that we can achieve Single Sign-on with another application via SAML.

      After authentication with IdP, I noticed our application would not work correctly. I traced it to the following code on our side: Object obj = SecurityContextHolder.getContext().getAuthentication().getPrincipal();. Our code expects the return of this to be a UserDetails object but we were getting a String back (user's name).

      I changed the following in your SAMLAuthenticationProvider: ExpiringUsernameAuthenticationToken result = new ExpiringUsernameAuthenticationToken(expiration, userDetails, credential, entitlements);

      Notice the "userDetails" being passed in as opposed to "principal". This fixes our problem. Our code works fine with the other providers from Spring Security as well.

      Would you consider this a bug? If so, would you be able to incorporate the fix I outlined above? Again, thank you very much for your contribution.

      Sincerely,
      Ray.

        Activity

        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:
            raichura Ray Raichura
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development