Package edu.uiuc.ncsa.oa4mp.delegation.client

Class DelegationService

  • All Implemented Interfaces:
    Server
    Direct Known Subclasses:
    DS2
    public abstract class DelegationService
extends Object
implements Server
    THE service API. This is a facade for the various bits of delegation a client needs to get a protected asset (mostly we are interested in certificates). The underlying messages might mutate, but the overall patterns do not vary much at all. This abstraction layer keeps those patterns and shoves everything that is implementation specific into separate modules. The nomenclature used throughout is OAuth 2.0:
    • Asset = the thing that is being delegated. Here usually it is a certificate.
    • Client = the application requesting delegation
    • Resource Owner = The person (or maybe thing) who owns the asset
    • Authorization Server = The server that authorizes access to asset
    • Resource Server = The server that actually has the asset
    Note that asset, protected asset and resource are all pretty much used interchangeably.

    The steps then are as follows.
    1. A resource owner tells a client to use a protected resource
    2. The client starts the request cycle. It gets an authorization grant and a uri pointing it to the authorization server.
    3. The owner grants authorization.
    4. The authorization server notifies the client via a callback, getting the authorization grant (which identifies the transaction) and a verifier showing resource owner approval.
    5. The client requests the asset using the grant and verifier.
    This is based on OAuth and it does the complete, specification compliant exchanges. However, since we have a few special cases which vastly streamline this, only a very simple API is really what a client needs.

    Generally applications will write to this to get their functionality and only in exceptional cases will use the implementations of the underlying service. Direct references to protocols (e.g. OAuth 1.0a) are inherently fragile and will break at some point, e.g. when trying to use OAuth 2.0. One of the strongest arguments for doing it this way is that services may have to support several types of requests (OAuth 1 and 2) and this design allows for keeping multiple instances cleanly separated.

    Created by Jeff Gaynor
    on Apr 4, 2011 at 3:51:41 PM

    • Constructor Detail

    • Method Detail

      • processDelegationRequest

        public DelegationResponse processDelegationRequest​(DelegationRequest delegationRequest)
        Starts the delegation process. This requests that the server permit delegation.
        Returns:

      • processAssetRequest

        public DelegatedAssetResponse processAssetRequest​(DelegatedAssetRequest delegationAssetRequest)
        Gets the asset once the delegation has been approved. This will typically involve getting tokens as needed from the authorization server then accessing the resource server, so this actually does two legs in the protocol in quick succession. If you need to do these separately, then invoke them as

        getAT
        getCert

        with the correct parameters.
        Returns:

      • getAtServer

        public ATServer getAtServer()
        The authorization server. This server issues access tokens.
        Returns:

      • getPaServer

        public PAServer getPaServer()
        The resource server. This server hosts the protected assets.
        Returns:

      • getAgServer

        public AGServer getAgServer()
        This server issues the authorization grant that starts the delegation process.
        Returns: