CAS Services Registry Improvements for CAS 3.5
The big picture
A kinder, gentler, more usable Services Registry with some features that make it more friendly for CAS adopters.
Specific improvements
Facelift
User story: A CAS administrator accesses the services registry, and expects a pleasant, beautiful, usable, tool-tip-assisted user experience.
Current behavior: The services registry has some styling and UI affordances. Cool. Cool. Can be improved.
Improvement: Apply UX design and UI implementation efforts, update to styling and skinning, make the services registry look better.
Who owns this: Jacob Lichner
Improve administrative UI over "evaluationOrder" property of registered services
User story: A CAS administrator creates overlapping entries in the services registry, one more specific than the other. E.g., he leaves the fundamentally open default of https://** but then adds a more specific match for https://somewhere.edu/someparticularservice . He must take care that his more specific registration has an earlier "evaluationOrder" so that it will have any effect – so that CAS will evaluate it before evaluating the wildcard match. If the https://** has an earlier "evaluationOrder" then it will always match https://somewhere.edu/someparticularservice and so the more specific registration will be pointless.
Current behavior: While evaluationOrder is an administrator-configured integer field editable and reviewable on editing a specific service, it isn't reflected in the ordering of services on the management overview screen, and so it is difficult for an administrator to understand and reason about in what order CAS will attempt to match services.
Improvement: Evaluation order of service registrations becomes more discoverable, more reviewable, easier to edit.
Who's working on this: Misagh Moayyed.
Per-service selection of which user attribute to treat as the username in the CAS protocol
User story: Not all applications consider the same user attribute to be the username, the identifier of the user, unfortunately. Sometimes this can best be addressed in the cas-using application. However, sometimes this can best be addressed by CAS simply releasing to the service the desired user attribute representing the username as that service sees it. When a CAS Administrator registers a service, he should be able to choose what attribute will serve as the username in the CAS protocol responses to that application – this ends up being a choice between the default behavior, one of the available user attributes, or the generated opaque identifier.
Current behavior: Administrators can choose between the default behavior and releasing a generated persistent opaque identifier in lieu of the default username to the service via the "Annonymous Access" checkbox.
Improved behavior: Administrators can choose between the default behavior, releasing one of the available user attributes in lieu of the default username, or releasing a generated persistent opaque identifier, as the username policy for each registered service.
Who's owning this: Andrew Petro.
Putting more teeth into disabling "Allowed to Proxy"
User story: When the CAS Administrator un-checks the "Allowed to Proxy" checkbox associated with a service in the services registry, that service should no longer be allowed to proxy.
Current behavior: Currently, un-checking the "Allowed to Proxy" property of a service causes CAS to issue no new Proxy Granting Tickets to that service, but existing PGTs continue to be honored. Depending upon ticket expiration policy, such a service might continue to obtain and use proxy tickets for a while after having been nominally disallowed from proxying.
Improvement: Improve to, un-checking the "Allowed to Proxy" property associated with a service continues to cause CAS to stop issuing PGTs to the service but further causes CAS to no longer honor any existing PGTs issued to the service and PTs derived from them.
Who's owning this: Dmitriy Kopylenko.
Making opting a service out of single sign-on more convenient
User story: When the CAS Administrator un-checks the "Participate in SSO" checkbox associated with a service in the services registry, that service should no longer participate in single sign-on. This should happen immediately, without reconfiguration of the Java CAS client library in the application. Disabling "Participate in SSO" should simply treat the service as if it always specifies "renew=true", opting it out of single sign-on.
Current behavior: Currently, disallowing a service from partipating in SSO causes CAS to enforce that the service sets renew=true on its login requests, but it does not automatically treat the service as if it had done so. This leads to user-facing warning message experiences when the client application fails to set renew=true and therefore does not fulfill the cas-server expectation set in its services registry entry.
Improvement: Improve to, un-checking the "Participate in SSO" property associated with a service causes CAS to treat the service as if it always set renew=true and therefore immediately accomplishes opting the application out of SSO without requiring the application to be itself configured for or even aware of this setting.
Who's owning this: Dmitriy Kopylenko.
Per-service opt-out of single logout callback
User story: Not all applications are prepared to handle a single logout callback. When a CAS Administrator registers a service in the service registry, he should be able to choose whether that particular service will participate in single logout. If registered as not participating, CAS should not execute a single logout callback on that service.
Current behavior: Single logout cofiguration is all-or-nothing and applications making use of CAS all get the single logout callback by default.
Improvement: CAS administrators will be able to decide which services receive the single logout callback by configuration of the service registrations in the service registry.
Interactive Service Matching Tester
Add a web-based administrative interactive service identifier matching tester UI. This would allow administrators to test which Services Registry entry will match an arbitrary service identifier, easing understanding and verifying the Services Registry configuration. The UI should show the Registry entry that will match and articulate how CAS will consequently treat requests to obtain service tickets to access the given service.
Use case: CAS administrator would like to verify how CAS intends to treat a particular service URL.
Current behavior: Requires manual testing or careful inspection of service registry data.
Improvement: Administrator-facing UI for simply entering the service URL into a form, submitting it, and getting feedback from CAS about what services registry entry matched and what the consequent behaviors will be.
Other improvements that probably aren't going to make it in time for CAS 3.5
Detect and warn when using a non-persisting service registry implementation
The default services registry implementation is fine for a demo, but it is only in-memory and does not persist service registration configuration across CAS server restarts. This may be surprising to CAS adopters.
In the case where the in-memory registry is used, the services registry web-based UI should reflect this, warning the administrator that all changes made through the UI are transient.
Use case: A new CAS adopter just getting started with the services registry tool is reminded when using the in-memory implementation that the changes he is making will no persist, allowing him to more quickly realize this and choose a persistent services registry implementation if he moves beyond just experimenting with the tool.
Current behavior: Currently the services registry UI allows an administrator to enter registration data to the default, transient, in-memory services registry implementation without warning that this data entered will disappear on restart.
Improvement: Services registry UI will advise when the changes being entered are not persisted across CAS server restarts because the default registry implementation is in use.
ReadOnlyContinuallyReloadingFileBackedServicesRegistryImpl
CAS-1025, would benefit from CAS-1026
An XML-file-backed implementation of ServicesRegistry, augmenting the existing In-Memory and JPA-backed options, affording a simple shared-state-across-clustered-CAS-servers live-updateable services registry implementation.
User story: A CAS administrator occasionally needs to update the set of registered services and the registration information about them in a clustered CAS environment but wishes to version this state as a file in source control.
Current behavior: There are JPA and Spring-wired-in-memory services registry implementations. There isn't an implementation that's file-backed and reloads itself. Currently in a clustered environment adopters must use the JPA implementation if they want to use an implementation shipping with CAS.
Improvement: Deployer can choose the file-backed implementation, point it at a simple XML file representing registered services, and then update this file as necessary, versioning and controlling change to this file through processes outside of CAS. Implementation periodically reloads the file and changed registration state takes effect without requiring CAS server restart.
Support for read-only services registry implementations
Enough metadata on the services registry API to allow flagging service registries as read-only, so that the UI can provide an appropriate administrative experience around this.
Use case: A CAS administator using a read-only services registry implementation, such as that proposed above, may nonetheless wish to review the current service registration configuration via the services registry web application. He should not be taunted with edit and add functionality that will not work given his choice of services registry. Rather, the UI should reflect that the registry is read-only.
Current behavior: Currently no particular support for CAS services registry UX awareness of read-only-ness of a services registry implementation.
Improvement: Adopters can use the services registry UI for reviewing the present registrations even when using a read-only services registry implementation.