[cas-dev] RESTful CAS API

[Scott Battaglia]

On Wed, Apr 23, 2008 at 10:52 AM, Smith, Matt <matt.smith at uconn.edu> wrote:

> Scott -
>
> <hat type="security">
>
>  If a service is trying to authenticate to CAS as itself, is
> ID/Password the right kind of credential?  Seems like a stronger
> mechanism could be encouraged by default.  Perhaps X.509 or similar?


The example uses username/password but the actual thing would go through the
entire service layer and thus can utilize any of the authentication
mechanisms the CAS service supports.

>
>
>  I also worry that this API makes it too "easy" for a service to pop-up
> a dialog box asking for a user's credentials, and perform validation,
> bypassing the whole WebISO thing without the CAS admin being aware.
> Yeah, it is possible today by screen-scraping the 'LT' param from the
> login script and submitting it with the ID/Password, but this API makes
> it much easier.  Defaulting this API to use a mechanism like X.509,
> GSSAPI/SPNEGO, etc eliminates this undesired use.


Again, this API doesn't make statements about what you should do.  That's
your own organizations call.  With our SOAP service at Rutgers, we can't
authenticate anything but service username/password through the SOAP
service.  Username/password for people fails. But that's a choice we made.
You'll also find people who would hope to integrate this with their desktop
clients who would want the ability to authenticate users.

Just as CAS doesn't tell you that username/password may or may not be strong
enough for people, it makes no statements about what your organization
should do with regards to securing services.  It makes available everything
that CAS has to offer and allows you to configure it to be as restrictive or
relaxed as you want.

>
>
> </hat>
>
> <hat type="developer">
>  Yeah -- those point do make the problem space *much* more complicated.
> But, they are important to consider anyway.
> </hat>


I disagree that it makes it much more complicated.  CAS has been designed
from the ground up to support (in theory) many different types of
credentials, and any restrictions (or lack of) associated with that.  This
is merely another layer on top of the service layer to marshal credentials
(much like the MVC layer is).  In fact, parts of the MVC layer may be able
to be reused.

These are all good points, but I believe the way CAS is designed allows for
you to be as restrictive (or unrestrictive as you want) in a fashion similar
to the MVC layer (but I suppose we'll see when we try to actually develop it
;-))

-Scott

>
>
> HTH,
> -Matt
>
> On Wed, 2008-04-23 at 09:32 -0400, Scott Battaglia wrote:
> > All,
> >
> > We have need of a way of programmatically obtaining tickets for
> > purposes of service to service authentication.  We've previously used
> > a SOAP-based web service (which we've kept internal).  We're planning
> > on moving to a much lighter approach, to make it easier for our
> > non-Java clients (SOAP isn't necessarily fun to parse/construct), but
> > we're most likely going to contribute it back as a module in the CAS
> > project, as it seems like something other people could use (and I
> > believe some people have hinted at needing something).
> >
> > To that end, we've posted a suggested API for obtaining TGTs and
> > Service Tickets:
> > http://www.ja-sig.org/wiki/display/CASUM/RESTful+API
> >
> > Please let us know if you have any feedback, additional ideas, etc.
> >
> > Thanks
> > -Scott
> >
> > --
> > -Scott Battaglia
> > PGP Public Key Id: 0x383733AA
> > LinkedIn: http://www.linkedin.com/in/scottbattaglia
> > _______________________________________________
> > cas-dev mailing list
> > cas-dev at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas-dev
> --
> Matt Smith
> matt.smith at uconn.edu
> University Information Technology Services (UITS)
> University of Connecticut
> PGP Key ID: 0xE9C5244E
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>


-- 
-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080423/36c475d0/attachment.html