Andrew, At Rutgers, we have the following in place, which while not a specific policy, has been the guidelines we have been using. As we move to return attributes via the CAS response, we're working on tightening up and defining IdM policies. Our IdM policies are not necessarily University policies at this point, but its probable that discussions around that would occur at some point:
Guidelines: 1. Any application that wishes to use CAS must request access. Our CAS server is not open to the world; there are restrictions. We do have some liberal policies with groups that we work closely with. i.e. we're more likely to approve a host name for an OIT organization whereas 3rd party applications are just about always by application. 2. Currently the only time SSO gets turned on is if you go to certain applications first, i.e. the portal or the RIAS project. All other times CAS is merely used as the authentication mechanism. This may change as we evolve the service further into a University-wide service. (in fact, I'm hoping it does) 3. Attribute release is currently only done via LDAP. There's a subset of public data that's available to anyone who requests a Service DN (as long as they agree to a bunch of terms). Third parties generally need an Institution sponsor. More controlled data such as course information is vetted by our Registrar before we grant access to it. A lot of this is a manual process right now. I'm confident that our policies and guidelines will continue to evolve as IdM gains more visibility within Rutgers so anything I said is subject to change :-) -Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Wed, Aug 27, 2008 at 4:56 PM, Andrew Feller <[EMAIL PROTECTED]> wrote: > *NOTE: This is a discussion thread of policies related to SSO and not a > question > * > In my discussions within my organization about SSO and how it relates to > the applications we provide to the university, there has been a major policy > question that is still being skirted: whether applications not supported by > the university's IT staff can use the CAS cluster established for > applications supported by the IT staff including applications managed by > individual departments / units and third-party vendors. > > The difficulty of the question is due to multiple factors / worries: > > *1.) Ensuring participating applications behave according to the policies > established > * > Since CAS is the SSO solution for all applications supported by the > university's IT staff and all supported applications are part of our portal, > then users sign out of the portal as a whole rather than individual > applications. There are concerns about applications signing users out of > CAS prematurely as well as applications only signing users out locally > rather than through CAS. > > *2.) Preventing dubious parties from obtaining users' information > * > In the past, we have had some departments / units create a mock-up of our > portal's login page where they were taking users' credentials, logging them > into the portal, and caching off the credentials. This is a blatant abuse > of IT services that was quickly dealt with. I realize that CAS 3.1 and > higher offer the service management feature that allows administrators to > determine which services can use SSO, so that should prevent unauthorized > use. > > As CAS deployers within your respective organizations especially > universities, have you encountered similar policy worries? Has there been > other policy worries that you have encountered that might be helpful for > others to learn from? > > Thanks, > Andrew > > Andrew R. Feller, Analyst > Information Technology Services > 200 Fred Frey Building > Louisiana State University > Baton Rouge, LA 70803 > (225) 578-3737 (Office) > (225) 578-6400 (Fax) > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
