For anyone going this route - be aware that the desktop version of Lync doesn't work with the ECP extension to Shibboleth. If you are planning on using Lync, you must use ADFS.
We're piloting an O365 deployment and wanted to have the Lync client working but also wanted CAS to be single user-interface for authentication, so I integrated CAS, Shibboleth and ADFS: * We've used CAS to protect Shib for about four years. We're using mod_auth_cas with Apache in front of Tomcat, but it's functionally equivalent to the setup documented here: https://wiki.jasig.org/display/CASUM/Shibboleth-CAS+Integration * Installed ADFS and configured it to trust Shibboleth as an Identity Provider: http://go.microsoft.com/fwlink/?LinkId=207916 (That guide is geared towards Sharepoint 2010, but it has all the necessary ADFS/Shib info) * Followed the standard MS directions for federating O365 and ADFS: http://www.microsoft.com/en-us/download/details.aspx?id=28971 * Based on information from that whitepaper, I found that the only data that the identity provider needs to send to ADFS after authentication is the Windows account name (DOMAIN/username). The "outgoing" claims transfer rules take that value, search AD and get the necessary claims needed for O365 access (UPN and objectGUID) * Since the windows account name isn't an LDAP attribute you can search for in AD, I had to configure Shibboleth to generate the attribute with a script, appending the username to "DOMAIN/" * Finally, I added JavaScript and CSS to the "ADFS Realm Discovery" page (where you select AD or Shibboleth as your Identity Provider) to automatically select Shibboleth and submit the form, so the user never sees that page at all. The result is that users accessing O365 through a browser are routed through ADFS->Shibboleth and finally authenticated by CAS, while thick clients (Outlook, Lync, etc) are authenticated directly by ADFS. This obviously requires CAS and ADFS to have the same credentials for all users, either by using AD as the credential store for CAS or synchronizing passwords between AD and whatever CAS authenticates with. Another advantage with this setup is that we can provide SSO for services that support CAS, Shibboleth or ADFS. Service providers can use whichever technology is the best fit for their application and since MS has said that their future products will rely heavily on ADFS, hopefully more products will support it out of the box. -Eric -- Eric Pierce Identity Management Architect Information Technology University of South Florida (813) 974-8868 -- [email protected] ________________________________ From: Jason A Everling [[email protected]] Sent: Thursday, December 06, 2012 5:24 PM To: [email protected] Subject: [cas-user] Re: [cas-user] Cas and o365 Email You can skip using ADFS all together, like you said before you already have shib and CAS talking. Just read the outline from microsoft to setup Shibboleth I linked a few emails ago, going from OWA > ADFS > SHIB > CAS is un-necessary. Would just be OWA > SHIB > CAS, it is almost immediate and user would see just your shin URL for a split second. Jason ----- Reply message ----- From: "Laura McCord" <[email protected]> Date: Thu, Dec 6, 2012 2:46 pm Subject: [cas-user] Cas and o365 Email To: <[email protected]> Yeah we are using ADFS and I think is that where the hang-up is occurring. Our consultant was going to use the documentation from the original post ( http://technet.microsoft.com/en-us/library/jj205456.aspx) but for some reason when he had a conversation with a person at MS, he was told that wasn't the way to go (sigh...I don't know why). Laura On Dec 6, 2012, at 2:36 PM, Kevin P. Foote wrote: Ahh.. OK. Yea you left out the ADFS bits.. :-) My main point was if you/Laura were thinking Shib would be yet another point for end users to 'login to', that would be incorrect.. Shib and CAS work nicely together to avoid just such a scenario. ------ thanks kevin.foote On Thu, 6 Dec 2012, Gasper, John wrote: -> Hey Kevin, -> -> I guess the point is we are an ADFS school, not Shib, and have been for several years. I probably also assumed that Laura was trying to use ADFS as that is what MS tends to push. -> -> My goal was to connect the two different SSO services (CAS and ADFS) and still retain the ability to federate (I originally modified ADFS to use CAS auth with the ClearPass extension). Someday, I should do more investigation with Shib, but it hasn't been a priority as of late. -> -> Besides writing the WS-Federation auth handler/plugin was a fun challenge. :) (Although Jérôme did the heavy lifting with the OAUTH connector.) It can be found here: https://github..com/jtgasper3/cas/tree/3.5.x/cas-server-support-wsfederation<https://github.com/jtgasper3/cas/tree/3.5.x/cas-server-support-wsfederation> -> -> John -> -> -----Original Message----- -> From: Kevin P. Foote [mailto:[email protected]] -> Sent: Thursday, December 06, 2012 10:20 AM -> To: [email protected]<mailto:[email protected]> -> Subject: RE: [cas-user] Cas and o365 Email -> -> On Wed, 5 Dec 2012, Gasper, John wrote: -> -> -> EWU is just about to go live with O365, so we had a similar need, but because we didn't want to have 2 un-connected single sign-on solutions we took a different approach. -> -> John, you are thinking about this wrong. As Jason mentioned before, user never knows the Shib portion is involved. Your SSO session would still be governed and provided fully by your CAS instance. You would not be adding an "un-connected sign-on solution". Rather, you would be extending the functionality of your current SSO solution to include the full SAML stack and yes the ECP portion which you would be after with o365. -> -> Just something to think about. -> -> ------ -> thanks -> kevin..foote -> -> -> -- -> You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -> -> -> -- -> You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> -> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -> -> -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user CONFIDENTIALITY NOTICE: This e-mail together with any attachments is proprietary and confidential; intended for only the recipient(s) named above and may contain information that is privileged. You should not retain, copy or use this e-mail or any attachments for any purpose, or disclose all or any part of the contents to any person. Any views or opinions expressed in this e-mail are those of the author and do not represent those of the Baptist School of Health Professions. If you have received this e-mail in error, or are not the named recipient(s), you are hereby notified that any review, dissemination, distribution or copying of this communication is prohibited by the sender and to do so might constitute a violation of the Electronic Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender and delete this e-mail and any attachments from your computer. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
