"shib-cas-authenticator" bridge

[Andrew Petro]

Alf.,

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.

To answer your questions:

1) where does the user authenticate; what controls the single sign-on
session?

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.

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.

2) what the IdP does

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.

3) How relying parties get attributes in this solution

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.

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.

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.


Hope this helps,

Andrew



On Fri, Apr 12, 2013 at 4:24 AM, W.Alphonse HAROUNY <wharouny at gmail.com>wrote:

> Hi all,
>
> In our company, we have capitalized on a CAS server and its working very
> well.
> Recently, we had to integrate a SaaS application into our SSO system,
> mainly for authentication.
>
> Unfortunately, the kinematic flow imposed by CAS was not compatible with
> the kinematic flow expected by the SaaS application.
> Actulally the SaaS application was not fully SAML compliant. Its was not
> able to deal correclty with the "SAMLArt" command generated by CAS.
>
> After googling on the net, I found the plugin "shib-cas-authenticator"
> https://github.com/Unicon/shib-cas-authenticator .
>  It's modules ("idp-ca-invoker" and "cas-authentication-facade") are
> located between Shibboleth IDP and CAS.
> It delegates authentication to the CAS server.
>
> 1/ Does the user fullfill his credentiels in the CAS login page ?
>     Does the validated SSO session by this plugin share the same CAS SSO
> session ?
>
> 2/ If CAS validates the credentials towards the users datastore, then the
> plugin will give back the "RemoteUser" to Shibboleth IDP.
>     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.
>     Is it right ?
>
> 3/ There is no Shibolleth-SP in the above solution, may a Shib-IDP release
> attributes to the SaaS application via the browser ?
>     Or is it mandatory that Shib-ID (Attribute Authority) releases
> attributes directly to Shib-SP (Attribute requester) ?
>
> Thank you in advance.
>
> Alf.
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130412/70cb9ad6/attachment.html