Scott, Thanks for info about the current state of things there at Rutgers! I forgot about attribute release as another on-going issue for ourselves. Traditionally, we have done attribute release by granting access to departments on campus to our databases on a read only basis. Recently, we were looking into instituting a university wide data warehouse, however due to budget, current priorities, and what not, we have decided to delay that initiative and begin providing attributes via LDAP to relieve load from the mainframe.
Thanks! Andrew On 8/27/08 9:20 PM, "Scott Battaglia" <[EMAIL PROTECTED]> wrote: > 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
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
