You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Universities have thousands of services and clients that must interact with REST APIs. Federated services may have millions of potential clients.  How can a client find a service, authenticate, and establish an identity? It is not feasible for each service to maintain credentials for each potential client.

Resources available from Internet2.

  1. Internet2 has a recommended identity solution for people users --- Shibboleth and InCommon metadata.
  2. Internet2 has an identity system for services --- InCommon Certificate Service.

User authentication is already well taken care of with Shibboleth.  A service can easily identify a user and know something about her (via attributes).  Federation allows services to identify users from different institutions.  Service authentication is well taken care of with InCommon certificates.  A service generally lives at a well know addresses and the certificate verifies ownership of the address.  Most clients do not have this luxury.

 Client/Service Registry

We propose 'SSO' support for API clients, provided by a per-institution 
registry of services and clients, federated by the InCommon trust model.

 A Client/Service Registry (CSR) at each institution, accessible by a standardized API, will provide:

  1. General information about each client and service,
  2. A chain of trust for each client and service.
  3. Maintenance of identity credentials for each entity in the registry.
  4. Temporary credentials for clients to any service in the registry.

It will be seen how easily this registry model is federated.

The Client/Service Registry (CSR) Resources

This describes resources and capabilities of the CSR.

Client and Service common attributes:

  1. Id: A unique identifier (similar to a user's netid or login id)

  2. Name and description: Administrators:  People or clients who can administer client information.
  3. Contacts:  People or groups who can be notified if action must be taken, or to certify the entity is still active.
  4. A sponsor:  A entity in the registry that certifies the identity of the service or client.  Each sponsor also has a sponsor.  As an example: client 'chem101a lab' is sponsored by 'Prof. Wimbly', who is in turn sponsored by 'Chemistry', which is sponsored by the root sponsor of the registry.  Through this chain of sponsorship the registry can provide identity assurance for its entities.

Additional attributes for Services:

  1. Service description URL:  What is it, details of its api, who should use it, etc.

  2. Service API URL components:  Host, port, etc.
  3. Supported authentication methods: Authorization service information:  if OAuth is supported.

Additional attributes for Clients:

  1. Host: if known and constant.

  2. Redirection URLs:  If OAuth is supported.

In addition the CSR maintains a long-term authentication credential to itself for each client in its registry.  A services will generally authenticate to the CSR with its InCommon certificate.


Credentialing

This describes the means by which a client gets a temporary credential and how a services verifies it.  Details depend on the type of credential.  'Temporary' means the credential can be easily renewed.  It does not specify any limits on the validity duration.

Basic authentication with an id and password:

  1. The client requests a password from the CSR:

    1. POST (CSR)/Token?type=basic&service=(service_id)

  2. The CSR generates a password (opaque string) and returns it to the client, along with expiry information.
  3. The client accesses the service, using Basic authentication with its id and the newly created password.
  4. The service asks the CSR to verify the password:
    1. GET (CSR)/Client/(client_id)>?token=(the password)
  5. If the password is valid the CSR returns the client's resource record, along with expiry information.
  6. Both client and service may cache the password for its lifetime.

Certificate authentication:

  1. The client generates a certificate request and requests a certificate from the CSR

    1. POST (CSR)/Token?type=certificate  ( the PEM certificate request is in posted content )

  2. The CSR signs the request and returns the signed certificate it to the client.
  3. The client accesses the service, using client certificate authentication.  Its id and the certificate expiry are contained in the certificate.
  4. The service verifies that the certificate was issued by the CSR and that it has not expired.

Note that, for its lifetime the certificate may be used with any service in the domain of the CSR.  The CSR does not maintain a CRL.

Other methods TBD:

  1. Signed message?
  2. JWT?

Federated Identity

Federation is easily accomplished because the institutional registries can know each other through the InCommon Registry of CSRs, and can mutually authenticate with InCommon certificates.
A client can, through the link between its own CSR and a remote service's CSR, obtain a credential to the remote service.  The service can, in turn, verify the credential at its own CSR and lookup the client through the same CSR to CSR connection.

 

 

Example scenarios

Federated access using Basic client authentication to the service

The scenario involves a collaboration between the University of Washington and Old Dominion University.

Definitions
  • CSR:  Client/Service Registry
  • UW:   University of Washington
  • ODU:  Old Dominion University
  • CSR.washington.edu:  Host address of UW's CSR
  • CSR.odu.edu:  Host address of ODU's CSR
The problem

Students at UW and ODU are working on a project.  As part of their collaboration an application at ODU needs access to groups maintained by a student (uwuser) at UW.  The application is a registered client with the CSR at ODU and has an id of 'c_ourapp@odu.edu'.
The group service is a registered service at UW's CSR with an id of 's_gws@washington.edu'.

The client and service are not necessarily Grouper.  They interact through the TIER REST API for groups.

The solution

(Assume a central registry of CSRs maintained by InCommon.)

  1. 'uwuser' adds 'c_ourapp@odu.edu' as a member manager (update privilege) of the groups she wishes to share.
  2. When the app needs to works with her groups it asks CSR.odu.edu for an authn token to the group service.
  3. ODU's CSR finds UW's CSR through the InCommon registry, and asks for the token.
    1. POST:  https://CSR.washington.edu/Token?type=basic&service=s_gws@washington.edu&client=c_ourapp@odu.edu )
  4. UW's CSR responds with token for c_ourapp@odu.edu to access s_gws@washington.edu.
  5. ODU's CSR responds to the app's original request with the same response.
  6. The client manages uwuser's group memberships through the group service's REST API, using the token as Basic authentication.
    1. Since the token was issued by UW's CSR it is easy for the group service to verify it.


Notes

Relationship to OAuth2

This proposal is not OAuth.  OAuth is not an authentication protocol. This does support OAuth however.

OAuth requires one client authentication—client to authorization service.  It does not, however, specify the authentication mechanism, nor the registration of the client, nor maintenance of the client's credential.  There is a suggestion for client self-registration, but it uses entirely client asserted information—not what we need.

Relationship to PKI

OAuth so totally abhors client certificate authentication that one wonders if its creators had bad experiences with  PKI as children.  We feel that client certificates, when used for very easy and well supported holder-of-key authentication, needs to be included in the list of possible authentication methods.

Relationship to RFC 7521

This was an attempt from a couple of years ago to use OAuth assertions for client authentication.  It seems forced and cumbersome, the very epitome of, "If you have a hammer...nail."  OAuth is not an authentication protocol.


 

  • No labels