<div dir="ltr">Alf.,<div><br></div><div style>Congratulations on your well-functioning CAS server. I think you're on the right track in adding a well-functioning Shibboleth IdP to operate alongside it and to integrate these so that the way users authenticate to the Shibboleth IdP is via CAS. I think they can work quite well together and form a flexible single sign-on platform for accomplishing these integrations in the different ways most practical for each integration.</div>
<div style><br></div><div style>To answer your questions:</div><div style><br></div><div style>1) where does the user authenticate; what controls the single sign-on session?</div><div style><br></div><div style>The end user presents credentials to and authenticates to CAS. CAS provides the single sign-on session in that typically the Shibboleth IdP should be configured in this integration to not itself accept an existing Previous Session as a means of authentication to the IdP, and instead always defer to CAS to authenticate the user.</div>
<div style><br></div><div style>This has the handy consequence of a user experience of a single sign-on session shared between CAS and Shibboleth, since after they log in, they'll have a CAS single sign-on session, and that will be sufficient to experience single sign-on to appropriate additional applications when they try, regardless of whether those applications integrate via CAS or via SAML to Shibboleth.</div>
<div style><br></div><div style>2) what the IdP does</div><div style><br></div><div style>The beauty of this integration approach is you have a real, full, well-functioning Shibboleth IdP. Users authenticate to the IdP via CAS, but relying parties can integrate with the Shibboleth IdP any way you like, leveraging its full SAML support, options, and featureset. So, the IdP might respond to Authentication Requests generated by the relying party, or you might do IdP-initiated logins. You might choose to integrate via a single sign-on profile involving signed SAML assertions that themselves include all the attributes the relying party expected. Or you might choose to integrate using an artifact profile and/or supporting attribute queries. All of the options, power, choices available to you and to the relying parties via the Shibboleth IdP is fully retained in the CAS+ShibIdP-bound-via-cas-shib-authenticator architecture.</div>
<div style><br></div><div style>3) How relying parties get attributes in this solution</div><div style><br></div><div style>In this solution, relying parties integrating via SAML are SAML service providers. Their integration is with your Shibboleth IdP via some profile, which might involve the end user conveying a signed (and encrypted) SAML assertion via the browser that contains all the identity information they need, or it might involve their calling back to the IdP to obtain more information. Depends on choice of profile.</div>
<div style><br></div><div style>What the relying parties don't do in this architecture, when they're integrating via SAML, is do anything whatsoever with CAS. They're not aware CAS is in the picture at all. CAS becomes an implementation detail of how the Shibboleth IdP authenticates users.</div>
<div style><br></div><div style>The relying parties might choose to implement their SAML participation by using the Shibboleth SP software, but there's no requirement that they use that specific software component, only that they fulfill the role of service provider in the SAML integration.</div>
<div style><br></div><div style><br></div><div style>Hope this helps,</div><div style><br></div><div style>Andrew</div><div style><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 12, 2013 at 4:24 AM, W.Alphonse HAROUNY <span dir="ltr"><<a href="mailto:wharouny@gmail.com" target="_blank">wharouny@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi all,</div><div><br></div><div>In our company, we have capitalized on a CAS server and its working very well.</div>
<div>Recently, we had to integrate a SaaS application into our SSO system, mainly for authentication.</div>
<div><br></div><div>Unfortunately, the kinematic flow imposed by CAS was not compatible with the kinematic flow expected by the SaaS application.</div><div>Actulally the SaaS application was not fully SAML compliant. Its was not able to deal correclty with the "SAMLArt" command generated by CAS.</div>
<div><br></div><div>After googling on the net, I found the plugin "shib-cas-authenticator" <a href="https://github.com/Unicon/shib-cas-authenticator" target="_blank">https://github.com/Unicon/shib-cas-authenticator</a> .</div>
<div>
It's modules ("idp-ca-invoker" and "cas-authentication-facade") are located between Shibboleth IDP and CAS.</div><div>It delegates authentication to the CAS server.</div><div><br></div><div>1/ Does the user fullfill his credentiels in the CAS login page ?</div>
<div> Does the validated SSO session by this plugin share the same CAS SSO session ? </div><div><br></div><div>2/ If CAS validates the credentials towards the users datastore, then the plugin will give back the "RemoteUser" to Shibboleth IDP.</div>
<div> As Shibboleth IDP is driving the authentication kinematic flow, then it will push the "RemoteUser" to SaaS application, instead of pushing a SAMLArt, like it was the case with CAS. </div><div> Is it right ?</div>
<div><br></div><div>3/ There is no Shibolleth-SP in the above solution, may a Shib-IDP release attributes to the SaaS application via the browser ?</div><div> Or is it mandatory that Shib-ID (Attribute Authority) releases attributes directly to Shib-SP (Attribute requester) ?</div>
<div><br></div><div>Thank you in advance.</div><div><br></div><div>Alf.</div><div><br></div><div><br></div>
<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br></div></div>