Page Comparison

...

Facelift

User story: A CAS administrator accesses the services registry, and expects a pleasant, beautiful, usable, tool-tip-assisted user experience.

...

Improvement: Apply UX design and UI implementation efforts, update to styling and skinning, make the services registry look better.

Who owns this: Unlicensed userJacob 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.

...

Improvement: Evaluation order of service registrations becomes more discoverable, more reviewable, easier to edit.

Who's working on this: Unlicensed userMisagh 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.

...

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: Unlicensed userAndrew 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.

...

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: Unlicensed userDmitriy 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.

...

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: Unlicensed userDmitriy 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.

...

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.

...

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.

...

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.

...

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.

...