Home page logo
/

educause logo Educause Security Discussion mailing list archives

Re: Multiple campus SSO security requirements
From: "Stewart, Ian" <istewart () UMASSP EDU>
Date: Tue, 4 Nov 2008 22:00:05 -0500

Hello David,

 

Do you mind if I quote a section of this document? I want to suggest we
use this as a model for a UMassTrust.

 

-Ian

 

________________________________

From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of David Walker
Sent: Tuesday, November 04, 2008 7:16 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Multiple campus SSO security requirements

 

Ian,

You're right that UCTrust is a SAML-based federation, but the document
defining its requirements says very little about technology and much
more about identity management practice, so you may want to look it
over:

http://www.ucop.edu/irc/itlc/uctrust/policy/trustpolicy032707.pdf


Our approach for dealing with the trust issue was to create minimum
standards that everyone has to meet, using the eAuthentication Level 2
as our model.  (Of course, we still had to do a lot of vetting of our
requirements with controllers, vice chancellors, CIOs, legal counsel,
etc., etc.)

David Walker
Campus IT Architect
Information and Educational Technology, Office of the Vice Provost
University of California, Davis
One Shields Avenue
Davis, CA 95616
(530) 752-9390
DHWalker () ucdavis edu

On Tue, 2008-11-04 at 06:36 -0800, Stewart, Ian wrote: 

 

In our case we are using a virtual directory for authentication and
authorization rather than doing SAML federation, but the trust issues
are the same and will set us up nicely for federating in the future. The
reasons for virtualization rather than a shib approach has to do with
the difficulty of federating PeopleSoft more than anything. Thanks for
the ideas so far. A University trust is what we need, with varying
levels of trust for different apps.

 

 

 

        
________________________________


        From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Steven Carmody
        Sent: Tuesday, November 04, 2008 8:15 AM
        To: SECURITY () LISTSERV EDUCAUSE EDU
        Subject: Re: [SECURITY] Multiple campus SSO security
requirements
        
        

         

        At 1:15 PM -0500 11/3/08, Stewart, Ian wrote:
        
        

                Hello,
                
                We are considering multi-campus web-SSO system that
allows an end-user to authenticate using their home campus LDAP account
or another campus LDAP account they may hold   Has anyone implemented
such a system and how have you dealt with the trust issues between
campuses that this creates? For example, each campus may have their
upfront ID-issuing or vetting process reviewed by all the other campuses
and an agreement signed before they are allowed to participate, as in a
federation.  Any thoughts on this issue would be welcome.

         
        
        

        It sounds like you want to create a system wide federation.
Several public state higher ed systems have already done this (eg see
UCTRUST, the Texas system, the NC system, etc). Sometimes the statewide
federation also includes state and local government; sometimes the plans
also include bringing in K12 at some point.
        
        

         
        
        

        You'd want your federation to set "common policy" for the
members. This might be a higher bar than is currently set by InCommon.
It might be useful, tho, to look at the recently promulgated InCommon
"Silver" standards, which match the federal e-authn Level 2 (and will
grant access to applications such as NIH grants mgmt, and (eventually)
Dept of Education FERPA).
        
        

         
        
        

        As a starting point, each campus would likely have some people
at "bronze" level, and a smaller set at Silver (people who need to
access applications in ways that engender a higher level of risk).
        
        


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]