Re: RESTful CAS API

Ahh .. excellent response - thanks.  My concern was that "username" and
password", from the example, would be an integral part of the API, but
you have alleviated that concern.

-Matt

On Wed, 2008-04-23 at 12:33 -0400, Scott Battaglia wrote:
> On Wed, Apr 23, 2008 at 10:52 AM, Smith, Matt <matt.smith@...>
> 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@...
>         > http://tp.its.yale.edu/mailman/listinfo/cas-dev
>         --
>         Matt Smith
>         matt.smith@...
>         University Information Technology Services (UITS)
>         University of Connecticut
>         PGP Key ID: 0xE9C5244E
>
>         _______________________________________________
>         cas-dev mailing list
>         cas-dev@...
>         http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>
>
>
> --
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
> _______________________________________________
> cas-dev mailing list
> cas-dev@...
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
--
Matt Smith
matt.smith@...
University Information Technology Services (UITS)
University of Connecticut
PGP Key ID: 0xE9C5244E

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev