Package org.oa4mp.server.loader.oauth2.servlet

Class OA2AuthorizedServletUtil

  • public class OA2AuthorizedServletUtil
extends Object
    This is set of calls to replace the old Authorized Servlet. It still has utilities for starting the auth code flow.

    Created by Jeff Gaynor
    on 5/14/18 at 12:14 PM

    • Constructor Detail

      • OA2AuthorizedServletUtil

        public OA2AuthorizedServletUtil​(OA4MPServlet servlet)

    • Method Detail

      • doDelegation

        public OA2ServiceTransaction doDelegation​(javax.servlet.http.HttpServletRequest req,
                                          javax.servlet.http.HttpServletResponse resp,
                                          boolean encodeTokenInResponse)
                                   throws Throwable
        Main entry point for this class. Call this. It does not do claims processing. That is done in the createRedirect(HttpServletRequest, HttpServletResponse, ServiceTransaction) which is the last possible point to do it.
        Parameters:
        req -
        resp -
        Returns:
        Throws:
        Throwable

      • doIt

        protected OA2ServiceTransaction doIt​(javax.servlet.http.HttpServletRequest httpServletRequest,
                                     javax.servlet.http.HttpServletResponse httpServletResponse)
                              throws Throwable
        Note the entry point for this is the doIt(HttpServletRequest, HttpServletResponse) method if authorization is done elsewhere (so the assumption is that authorization has already happened), vs. the doDelegation call that is invoked by the OA4MP Authorize servlet. The difference is that the two paths will invoke the claims processing at different points.
        Parameters:
        httpServletRequest -
        httpServletResponse -
        Returns:
        Throws:
        Throwable

      • getAndCheckResponseTypes

        protected List<String> getAndCheckResponseTypes​(javax.servlet.http.HttpServletRequest httpServletRequest)
        This will take the HttpServletRequest and pull out the response_type. If the response type is not supported (e.g. implicit flow), an error is raised.
        Parameters:
        httpServletRequest -
        Returns:

      • CheckIdTokenHint

        protected OA2ServiceTransaction CheckIdTokenHint​(javax.servlet.http.HttpServletRequest httpServletRequest,
                                                 javax.servlet.http.HttpServletResponse httpServletResponse,
                                                 String callback)
        In this case, a previous request to the token endpoint returned an ID token. If this is sent to this endpoint, we are to check that there is an active logon for the user (=there is a transaction for that name here) and return a success but no body. Otherwise, we throw an exception.
        Parameters:
        httpServletRequest -
        httpServletResponse -
        callback -
        Returns:

      • checkPrompts

        protected void checkPrompts​(OA2ServiceTransaction transaction,
                            Map<String,​String> map)
        Basically, if the prompt parameter is there, we only support the login option.
        Parameters:
        map -

      • figureOutAudienceAndResource

        public void figureOutAudienceAndResource​(TransactionState state)

        RFC 8707 support.

        Internally we call it audience (since the aud claim is returned), but the difference is that a resource is a list of URIs and the audience is a list of logical names or URIs. Generally we encourage people to just use the resource parameter.

        Especial note: The resource and audience configuration lives in the access token configuration of the client.

        According to 2.1 in RFC 8707:
        "In the code flow (Section 4.1 of OAuth 2.0 [RFC6749]) where an intermediate representation of the authorization grant (the authorization code) is returned from the authorization endpoint, the requested resource is applicable to the full authorization grant."

        We return these in the access token. We do allow that the user can pass these in as part of the authorization request, but merely record the fact for the access token, since we do not have some use of resource/audience for authorization grants. The spec simply (seems) to state that if it is present in the auth request, it should apply to that too.

        Parameters:
        state -