I'd use the RBAC support in Unicon's CAS-addons (https://github.com/Unicon/cas-addons/wiki/Role-Based-Services-Authorization). You could add a rule to all of the services you want to protect that checks for a particular attribute value that is set when they've completed your training requirement. If they don't have the attribute, they'll be redirected to a URL you specify where you can explain why they can't reach the requested service.
BTW, that capability (with different configuration) has been merged into CAS 4.1.0 -Eric ________________________________ Eric Pierce, CISSP Identity Management Architect | USF Information Technology epie...@usf.edu | Tel: (813) 974-8868 Please note: Due to Florida’s broad open records law, email to or from University employees is public record, available to the public and the media upon request. ________________________________________ From: Tom Poage <tfpo...@ucdavis.edu> Sent: Wednesday, October 7, 2015 5:43 PM To: cas-user@lists.jasig.org Subject: [cas-user] Multiple service registries? CAS server (3.5.x at the moment). I've been asked to look into feasibility of restricting access of a dynamic subset of users to a subset of CAS clients based on a criterion evaluated at the CAS server. If the user meets the condition, they have unrestricted access to our CAS clients. If the user does not, they may access only a (severely) restricted set of CAS clients. Specifically, this is to meet a training requirement, with a penalty (the restriction) imposed for not doing so. My initial thought is to try to wire in two service registries, one restricted, the other unrestricted, with a bit of glue code to keep track of them, then use a PersonDirectory attribute(s) as condition on which registry to choose. The general CAS Spring webflow seems to start with validating a service (from a single service registry) before moving on to the credentials webflow. In my 'hypothetical' case, I'd need to invert that: resolve the user and attributes, then use that information to choose which set of valid services to test (cf. ssoEnabled). To me, this sounds like a fair amount of risky work. Anyone have/use a case like this before? How did you approach it? If not, how might one approach this? Any different for CAS 4.x? Thanks! Tom. -- You are currently subscribed to cas-user@lists.jasig.org as: epie...@usf.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
