Main Nav

Has anyone found a good solution to authenticating across multiple cloud-based sites?  We have been looking at a provider named PingIdentity to try to tie our sites together, but it’s expensive and it’s hard to get all the players to agree to using the Ping model.

 

It seems that our new business model is going to lead us to have more and more cloud-based solutions which need to interoperate well together in order to give our students a seamless experience (LMS, electronic library, ePortfolio, discussion forums, etc.).  Most allow themselves to be branded fairly easily so that users will not notice that they’re going from one site to another, but very few are sophisticated in their use of web-based authentication standards like SAML.  As a result, even though the sites look similar, each needs to ask the user to authenticate (potentially with a different ID than other sites in the system and often with a different password).  We, of course, want to avoid having to authenticate anywhere but on our portal.  Nirvana would be the ability to authenticate at any one site in the system and be able to go to any other site in the system without having to authenticate again – which is the PingIdentity model.

 

Has anyone cracked this nut?

 

Thanks much!  Greg.

 

Greg Kozak

VP, Information Technology

Lake Forest Graduate School of Management · 1905 W. Field Court · Lake Forest, IL 60045

847.574.5194 (direct) · 847.707.0712 (cell) ·  847.234.5005 (main)

gkozak@lfgsm.edu

 

Lake Forest Graduate School of Management

BROAD THINKERS | STRONG LEADERS

www.LakeForestMBA.edu

 

 

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

Greg, I'm assuming that you have looked at InCommon, http://incommon.org/ . If not, that is a good place to start. Soapbox on: Quoting Franklin, "We must, indeed, all hang together, or assuredly we shall all hang separately." As higher ed talks about collaboration and cooperation it really makes a difference when schools talk to vendors and ask them to support inCommon and mention it is our Higher Ed Standard. Most vendors I talk with quickly realize how easy it is to support InCommon and the benefits it offers. Once that happens many jump at this. Also, since what you want to do is what we all want to do, supporting InCommon to do it is a competitive advantage for companies and enables the other members of InCommon to leverage this -- why should we pay a third party to do what we can do ourselves. As chair of InCommon Steering, I can say that InCommon is working hard to serve the needs of higher ed and there is a lot of activity in the pipeline that is focused on solving these kinds of needs. As part of InCommon, I've been been engaged in the Internet2 NET+ discussions and there is a lot interest in that program, which will require InCommon for vendors and participants. I know many schools and companies believe InCommon is too complicated to set up but over the last few years InCommon has as added a number of companies as affiliates that can help you get up and running quickly and without a lot of technical expertise. InCommon wants to serve the needs of higher ed. If you, or any others have questions drop me a note, I'd be glad to discuss offline. jack suess, VP of IT & CIO, UMBC
Greg,

Good afternoon. I'll second Jack Seuss's recommendation of InCommon. Furman recently joined and we're planning to authenticate with our first InCommon vendor, PeopleAdmin, in the very near future.

Besides InCommon, we've also had good luck working with a company called SSOeasy http://www.ssoeasy.com/

Good luck.

Fred

From: The EDUCAUSE CIO Constituent Group Listserv <CIO@LISTSERV.EDUCAUSE.EDU>
Date: Fri, 17 Feb 2012 17:17:09 -0500
To: <CIO@LISTSERV.EDUCAUSE.EDU>
Subject: [CIO] Cloud-based multi-site authentication

Has anyone found a good solution to authenticating across multiple cloud-based sites?  We have been looking at a provider named PingIdentity to try to tie our sites together, but it’s expensive and it’s hard to get all the players to agree to using the Ping model.

 

It seems that our new business model is going to lead us to have more and more cloud-based solutions which need to interoperate well together in order to give our students a seamless experience (LMS, electronic library, ePortfolio, discussion forums, etc.).  Most allow themselves to be branded fairly easily so that users will not notice that they’re going from one site to another, but very few are sophisticated in their use of web-based authentication standards like SAML.  As a result, even though the sites look similar, each needs to ask the user to authenticate (potentially with a different ID than other sites in the system and often with a different password).  We, of course, want to avoid having to authenticate anywhere but on our portal.  Nirvana would be the ability to authenticate at any one site in the system and be able to go to any other site in the system without having to authenticate again – which is the PingIdentity model.

 

Has anyone cracked this nut?

 

Thanks much!  Greg.

 

Greg Kozak

VP, Information Technology

Lake Forest Graduate School of Management · 1905 W. Field Court · Lake Forest, IL 60045

847.574.5194 (direct) · 847.707.0712 (cell) ·  847.234.5005 (main)

gkozak@lfgsm.edu

 

Lake Forest Graduate School of Management

BROAD THINKERS | STRONG LEADERS

www.LakeForestMBA.edu

 

 

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

From our experience at Renssalaer (nee RPI), I agree with Jack Suess' exhortation about joining InCommon, although I prefer Red Green's context ("We're all in this together") to the less sanguine Benjamin Franklin quote. We joined InCommon just about a year ago. We had been intending to join for some time, but our immediate motivation was that Digital Measures required InCommon authentication, not just Shibboleth authentication, for "single signon". At that same time, we were discussing same signon with one of our longtime vendors, Benelogic. Benelogic had previously implemented a similar solution with another customer using Windows Active Directory Federation Services (ADFS). As we were implementing Shibboleth for our InCommon membership , and ADFS can interoperate with Shibboleth, Rensselaer asked BeneLogic to work with us on a Shibboleth-based implementation. As Benelogic had just demonstrated Shibboleth interoperability with their SSO project with Rensselaer, and InCommon uses Shibboleth as its single sign-on and federating software, Rensselaer encouraged Benelogic to join InCommon, as we had recently done. The value proposition of InCommon and business case for joining InCommon was evident to Benelogic; instead of negotiating, vetting and testing with institutions individually, Benelogic could offer their SSO solution to all 200+ research centers and institutions of higher education simply (more or less) by joining InCommon. From the Rensselaer perspective, InCommon serves as a discovery (and vetting) service, so that if/when we change our authentication infrastructure, we do not have to notify each and every business partner. In the Spring 2011, Benelogic asked Rensselaer to sponsor their InCommon membership, and Rensselaer was delighted to do so. Buoyed by our very positive experience with Benelogic, we very recently asked one of our newest vendors to join InCommon to provide authentication for their product. They responded, "We are familiar with it, but we are not members. We have about 20 deployments of Shibboleth and some of those are members of InCommon". I have brought this to product management in the past, but it has not been something we have been willing to set up, I think especially since we have easily deployed at these other locations without incurring the additional costs. We also support CAS, and have a basic SSO model that we can follow, but even without InCommon, we should still be able to share metadata and align our Shibboleth environments." I think this vendor, which has many, many customers in higher ed, misses an important point - namely that while they do not incur the cost of InCommon membership, we (and their other customers) incur the additional costs of working with them individually to bring this solution to our campus. We reviewed the InCommon "Sponsored Partners" list at http://www.incommon.org/participants/ to see which of our other vendors are InCommon members, to identify other opporutnities to exploit the InCommon authentication services. Gary Schwartz Director Communications & Middleware Technologies, RPI schwag@rpi.edu ________________________________________ From: Jack Suess [jack@UMBC.EDU] Sent: Friday, February 17, 2012 6:54 PM Subject: Re: Cloud-based multi-site authentication Greg, I'm assuming that you have looked at InCommon, http://incommon.org/ . If not, that is a good place to start. Soapbox on: Quoting Franklin, "We must, indeed, all hang together, or assuredly we shall all hang separately." As higher ed talks about collaboration and cooperation it really makes a difference when schools talk to vendors and ask them to support inCommon and mention it is our Higher Ed Standard. Most vendors I talk with quickly realize how easy it is to support InCommon and the benefits it offers. Once that happens many jump at this. Also, since what you want to do is what we all want to do, supporting InCommon to do it is a competitive advantage for companies and enables the other members of InCommon to leverage this -- why should we pay a third party to do what we can do ourselves. As chair of InCommon Steering, I can say that InCommon is working hard to serve the needs of higher ed and there is a lot of activity in the pipeline that is focused on solving these kinds of needs. As part of InCommon, I've been been engaged in the Internet2 NET+ discussions and there is a lot interest in that program, which will require InCommon for vendors and participants. I know many schools and companies believe InCommon is too complicated to set up but over the last few years InCommon has as added a number of companies as affiliates that can help you get up and running quickly and without a lot of technical expertise. InCommon wants to serve the needs of higher ed. If you, or any others have questions drop me a note, I'd be glad to discuss offline. jack suess, VP of IT & CIO, UMBC
Message from shelw@berkeley.edu

Gary, your point below is really key here.  The vendors will (and do) respond to our needs if we are clear in our requirements and there is sufficient demand across our community to make it worth their while to do so.    Integration with InCommon represents an opportunity to lower everyones costs - campuses, vendors, partners - in ways that few other community collaborations can do because we are all writing to and consuming metadata with a common standard and exchange point. Your campus is in control of what attributes are released, InCommon is a community owned asset that serves as the IdP,and the providers do have the expense of tailoring their product to everyone one of our unique campus approaches.   We have begun asking our commercial providers if they have support specifically for InCommon and have worked with those who are interested to establish that support.   Additionally for services that Berkeley may want to make available to other campuses, having InCommon in place allows us to expose those services for easier consumption by others.   

Shel


Shelton Waggener
Associate Vice Chancellor
Chief Information Officer
University of California, Berkeley
phone: 510.642.4096



Expanding a bit on what Shel has said, the University of California has sample language that can be added to RFPs and/or contracts for software and services to specify that the vendor be an InCommon member:

http://www.ucop.edu/irc/itlc/uctrust/rfplang_trustinteg.html

David Walker

On Wed, 2012-02-22 at 05:40 -0800, Shelton Waggener wrote:
Gary, your point below is really key here.  The vendors will (and do) respond to our needs if we are clear in our requirements and there is sufficient demand across our community to make it worth their while to do so.    Integration with InCommon represents an opportunity to lower everyones costs - campuses, vendors, partners - in ways that few other community collaborations can do because we are all writing to and consuming metadata with a common standard and exchange point. Your campus is in control of what attributes are released, InCommon is a community owned asset that serves as the IdP,and the providers do have the expense of tailoring their product to everyone one of our unique campus approaches.   We have begun asking our commercial providers if they have support specifically for InCommon and have worked with those who are interested to establish that support.   Additionally for services that Berkeley may want to make available to other campuses, having InCommon in place allows us to expose those services for easier consumption by others.   


Shel




Shelton Waggener
Associate Vice Chancellor
Chief Information Officer
University of California, Berkeley
mailto: shelw@berkeley.edu
phone: 510.642.4096





We are using the GLUU appliance to ease our entry into Shibboleth and InCommon.


We had looked into commercial SAML vendors like PingIdentity and other vendors and are very happy with our choice of GLUU.

I inform all vendors about InCommon and encourage them to support InCommon.   



Cindy King, Ph.D., Chief Information Officer
Gallaudet University, 800 Florida Avenue, NE Washington, DC 20002-3695
Campus Address: EMG Memorial Building, Room B01B
(202) 670-5159 (Google voice) 202-651-5159 (voice) 
202-559-5681 (video phone)  202-651-5454 (tty) 202-651-5213 (fax)
Email: cynthia.king@gallaudet.edu   Skype: GUcynthia.king
http://www.gallaudet.edu/cio.html
--------------------------------------------------
Note: This e-mail and all attachments are covered by the Electronic Communication Privacy Act, 18 U.S.C. §§ 2510-2521 , and are confidential.  If you are not the intended recipient  please notify the sender and delete the email and all attachments.  Any unauthorized retention, dissemination, distribution or copying of this communication is strictly prohibited.  Thank you.


Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.