Leverage OAuth server support on Spring Security OAuth library and add missing grant types

All Open JIRA issues are now moved to Github, and tracked under Github Issues. The migration is now complete. Please use Github issue tracking to file and track issues. JIRA issues will be closed.

The URL address for Github issues of the CAS project is:
https://github.com/Jasig/cas/issues

As far as the /profile endpoint is concerned, we can define that as a convenience endpoint for the integrator, but it's not strictly required for OAuth 2 compatibility.

Below is a summary of where this stands, with some relevant background.

Vanilla CAS supports user authentication and authorization for a service (as defined in the CAS service registry in "deployerConfigContext.xml"). The expected use case is that the end-user interacts with a CAS instance running in a container to obtain a CASTGC, which is to be used for authentication and authorization in subsequent requests made by a supported client (such as "spring-security-cas").

OAuth models user and client authentication/authorization. For an OAuth wrapper to be defined we need to either:

• Extend CAS to support a second set of credentials to represent the client authorization/authentication

• Assume all clients are authenticated/authorized and only check the username/password

• A partial solution in between the above two

The current wrapper (3.5.x release) represents client authentication, but not authorization. The client is assumed to be authorized. For this ticket to be complete this behavior will be replicated, except for using spring-security-oauth.

Spring Security OAuth requirements:

• Client Details Service: Tells spring-security where to find valid clients and for what grant types they are authorized. Currently implemented by defining a special type of service inside the service registry. Optionally can define scopes and resources to further restrict access on a per-client basis.

• Token Services: Handles creation and validation of OAuth 2.0 access tokens. Currently implemented by extending spring-security-oauth's DefaultTokenServices and replacing the UUID generated for the token string with the related user's Ticket Granting Ticket. Needs more work to be done since the user can be logged in multiple places.

• Token Store: Handles storage, retrieval, serialization, and deserialization of access tokens. Currently implemented as a wrapper that uses the CAS ticket registry, but given the nature of access tokens we'll need some other storage solution to be able to accurately identify the client, user, and service that's represented by the access token.

If we can accurately define the above solutions in CAS we can let spring-security-oauth handle the rest of OAuth, such as the authorization callback.

Created https://apereo.atlassian.net/browse/CAS-1313#icft=CAS-1313 for the other grant types.

Yes, it makes sense : let's focus on authorization code and implicit grant types in this ticket.

Would you mind opening a new ticket for the other grant types ?