CXF
  1. CXF
  2. CXF-4675

Move createUserSubject from RedirectionBasedGrantService to the OAuthDataProvider

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.7.0
    • Fix Version/s: 2.6.4, 2.7.1
    • Component/s: JAX-RS Security
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      I'm having to extend RedirectionBasedGrantService and consequently ImplicitGrantService in order to override createUserSubject. Would it be possible to move createUserSubject to the OAuthDataProvider?

        Activity

        Hide
        Sergey Beryozkin added a comment -

        Not sure about it - IMHO OAuthDataProvider does not have to deal with managing end-user subjects. It may create a Client subject but I'm not 100% that is correct either. Why don't you register a CXF RequestHandler filter and create the end user subject from there, as suggested in the other JIRA ?

        Show
        Sergey Beryozkin added a comment - Not sure about it - IMHO OAuthDataProvider does not have to deal with managing end-user subjects. It may create a Client subject but I'm not 100% that is correct either. Why don't you register a CXF RequestHandler filter and create the end user subject from there, as suggested in the other JIRA ?
        Hide
        Steven Tippetts added a comment -

        Thanks, I'll set up a RequestHandler rather than extending the objects. However, proceeding this way makes my implementation disjointed. It would be better for me if the OAuthDataProvider managed the createUserSubject method.

        Show
        Steven Tippetts added a comment - Thanks, I'll set up a RequestHandler rather than extending the objects. However, proceeding this way makes my implementation disjointed. It would be better for me if the OAuthDataProvider managed the createUserSubject method.
        Hide
        Sergey Beryozkin added a comment -

        That is a reasonable argument for the case where a user subject creation has to be customized. The question remains though, whose responsibility it is to get the subject capturing the info about the authenticated user or client identity ? IMHO it is out of scope for the data provider, otherwise where is the limit between what the runtime does and what the provider does ? For your custom provider it may make sense, for others could be an extra implementation issue...

        I may be wrong of course . If we see that in some cases the internal info that OAuthDataProvider may have can indeed help with properly creating a customized UserSubject then it can be reviewed - I'd probably introduce some other interface... Hmm... May be I can do it now....

        Show
        Sergey Beryozkin added a comment - That is a reasonable argument for the case where a user subject creation has to be customized. The question remains though, whose responsibility it is to get the subject capturing the info about the authenticated user or client identity ? IMHO it is out of scope for the data provider, otherwise where is the limit between what the runtime does and what the provider does ? For your custom provider it may make sense, for others could be an extra implementation issue... I may be wrong of course . If we see that in some cases the internal info that OAuthDataProvider may have can indeed help with properly creating a customized UserSubject then it can be reviewed - I'd probably introduce some other interface... Hmm... May be I can do it now....
        Hide
        Sergey Beryozkin added a comment -

        SubjectCreator interface has been introduced - this will let you bring the customization closer to the data provider - have the bean implementing OAuthDataProvider also implementing SubjectCreator. IMHO it is a good compromise as it will let the providers which are not into UserSubject customization not to worry about it, thanks

        Show
        Sergey Beryozkin added a comment - SubjectCreator interface has been introduced - this will let you bring the customization closer to the data provider - have the bean implementing OAuthDataProvider also implementing SubjectCreator. IMHO it is a good compromise as it will let the providers which are not into UserSubject customization not to worry about it, thanks
        Hide
        Steven Tippetts added a comment -

        Perfect. Thanks!

        Show
        Steven Tippetts added a comment - Perfect. Thanks!

          People

          • Assignee:
            Sergey Beryozkin
            Reporter:
            Steven Tippetts
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development