Hi, I think the missing piece here is WIF (Windows Identity Foundation). This seems to be the preferred authentication mechanism in .NET 4.0. It looks like SharePoint 2010 is using it now and I'm sure the rest of the MS server applications won't be far behind.
There was an excellent presentation on something like this at the Microsoft Professional Developer Conference by Vittorio Bertocci, titled "Identity & Access Control in the Cloud" (http://bit.ly/8ZnXbT). It showed plugin-based providers for the purpose of authentication & authorization in cloud-based applications (Azure). He showed how you could plug Facebook and Google's own HTML-based authentication into applications with minimal coding. While there is no provider for CAS servers yet, this is pretty much the same idea. If you make any progress, it would be a very valuable contribution to the .NET CAS Client. It will take a little effort to separate the authentication & claims-based content & implementation details from the MS cloud technology stack (Azure), but I'm pretty confident that they aren't inter-dependent. Here are a few resources to get started: http://social.technet.microsoft.com/wiki/contents/articles/windows-identity-foundation-wif-and-azure-appfabric-access-control-service-acs-survival-guide.aspx http://code.msdn.microsoft.com/wifwazpassive http://social.msdn.microsoft.com/Forums/en-US/Geneva/threads/ http://download.microsoft.com/download/7/D/0/7D0B5166-6A8A-418A-ADDD-95EE9B046994/WindowsIdentityFoundationWhitepaperForDevelopers-RTW.pdf http://msdn.microsoft.com/en-us/library/ff650503.aspx -ScottH -----Original Message----- From: Andrew Petro [mailto:[email protected]] Sent: Wednesday, January 26, 2011 5:19 PM To: [email protected] Subject: Re: [cas-user] CAS and ADFS integration Agreed. Whether the "single" part of SSO is achieved depends on whether the authentication to the portal via ADFS incurs a SAML round trip and thereby requires authentication via Shibboleth, which would then be CASified. If you've set up ADFS such that using ADFS to authenticate to the portal itself entails logging into ADFS via SAML and, in the proposed configuration, therefore a CAS login, then you'll get single sign on from that point on when you access another CASified application. (Or Shibbolized application, or ADFS-ified application). If the ADFS authentication to the portal does not entail SAML-authenticating to ADFS, then I agree the requirement of a user experience of single sign on won't be met. To the extent that ADFS and the partner's portal isn't under your control, Shibbolizing it is going to be a non-starter. Andrew On 01/26/2011 03:16 PM, Marvin Addison wrote: >> It's a bit, um, involved, but it should work, with the user logging >> in to CAS once, and then experiencing SSO each time the request >> traverses the stack. > The integration path Andrew sketched out doesn't meet the following > requirement as I understood it: > > "Note that simply using LDAP for authenticating against Active > Directory is not a good enough solution for us, since it will require > the users to login again, instead of relying on their login to our > partner's portal." > > I read the above as the user authenticates to an ADFS-secured portal > and it's desirable to leverage that authentication to transparently > authenticate to CAS. I'm not aware of any solution that would meet > that requirement. > > The solution Andrew outlined does provide an integration path, but it > requires an additional login to CAS for the workflow above. If you > could force all users through CAS from the start, then you could > achieve true single sign-on, but I imagine that may not be possible. > > M > -- 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
