Shibboleth Developers

["Scott Battaglia" <>]

Joe,

Not to hijack this conversation as this is a shibboleth-dev list, but some of the features you are looking at will be supported in CAS 3.1.  I would recommend you take a look at the CAS 3.1-m2 release (we're also going to support SAML to continue to allow for interoperability with Shibboleth).

If you're looking at CAS-Shibboleth best practices, K.U. Leuven has done a lot of CAS/Shibboleth integration:
http://shib.kuleuven.be/

-Scott

On 4/23/07, j.g. pawletko <> wrote:

Hello Scott,

Thank you for your comments.

Our approach differs from CAS a little in that the "service" parameter value
is a key to a relation instead of the callback URL itself. This allows us to
control which web applications use the authentication service and, in the
future, enables us to select the attributes that should be associated with a
ticket on a per-service basis.

For example, here is a sample redirect from the CAS documentation:
https://secure.its.yale.edu/cas/servlet/login?service=http://www.yale.edu/tp
/authenticate.jsp

whereas our redirect looks like this:
http://dlibdev.nyu.edu/authn/authn.cgi?service=sr_hidvl

The authn.cgi script will only redirect to the callback URL associated
with "sr_hidvl" in the (service, callback URL) relation.

Our current implementation only associates the 'eduPersonPrincipalName'
attribute with a ticket, however future implementations could use a
(service, attribute list) relation to associate attributes with tickets
on a per-service basis.  If different web applications require different
attributes these could be mapped to the service name in the (service,
attribute list) relation.

Perhaps this is overkill and if there are "best practice" CAS + Shibboleth
implementations I would be very interested in reading about them so we don't
re-invent the wheel.

Thank you for your time.

regards,
Joe


On 4/23/07 1:11 PM, "Scott Cantor" < > wrote:

>> Any comments you have are appreciated.
>
> My general question is why the need to invent yet another SSO protocol
> behind the gateway, as opposed to using some existing SSO protocol behind
> it.
>
> For example, you reviewed CAS...why not just use CAS itself? That's been
> done by others, I believe.
>
> -- Scott
>
>

--
J.G. Pawletko (joe)


Programmer/Analyst
Digital Library Team
Bobst Library, New York University
(212) 992-9999
--

-- 
-Scott Battaglia

LinkedIn: 
http://www.linkedin.com/in/scottbattaglia