Shibboleth Developers

["j.g. pawletko" <>]

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
--