Services Management

Owned by ScottS
Last updated: Jan 26, 2007 by Marvin AddisonVersion comment
2 min read

By default, CAS allows any third party client to use it as an authentication provider. CAS3 provided an ad-hoc way to restrict the clients allowed to use CAS. This design, however, was an add-on to CAS, that was not as polished as it could be (as it was meant to be an example). CAS 3.1 should include a "first-class citizen" version of the Services Management. Some required features are listed below:

  • Ability to not use the Services Management (not everyone would want to use this)
  • Ability to register services as "groups" (i.e. use wildcard to identify groups or using regular expressions).
  • Ability to disable/enable services easily
  • Administration Screens
  • Ability to restrict which attributes are returned to services.
  • Ability to restrict who can proxy (is this necessary?)
  • Ability to "theme" page based on service [necessary since CAS can act like Google Accounts and be embedded on application pages?]
  • Ability to enable/disable participation in single sign on
  • Optional database backing of services. Virginia Tech has some code that may be helpful for this piece.
  • Extend the properties of the RegisteredService class:
    • ServiceName - user friendly name of service
    • Description - description of service/group of services
    • RequestedURL - the actual URL that was requested (may differ from registered group URL)

(A brief note from Marvin Addison, CAS developer at Virginia Tech)
The requirement of allowing wildcards is fundamentally problematic for us. We need the registered service URL to be a valid URL, and we want a one-to-one mapping between registered service and logical service. These needs are related to our use of registered services for single sign-out. If anyone is interested in how we have used registered services to implement single sign-out, please see the VT CAS Wiki.

We have a need to register "groups" of services as one, but we have some host/path restrictions, for example:

Registered service: https://example.com/root
Allowed: https://example.com/root/service1 and https://example.com/root/service2
Denied: https://example.com/ and https://www.example.com/root

We implement this through an alternative implementation of DefaultServiceRegistry, FuzzyServiceRegistry, where we do URL analysis. I imagine our host/path requirements may be too restrictive for many cases.