[cas-dev] RESTful CAS API
Scott Battaglia
scott.battaglia at gmail.com
Wed Apr 23 13:10:12 EDT 2008
I suppose I should put more examples up ;-)
On Wed, Apr 23, 2008 at 1:01 PM, Smith, Matt <matt.smith at uconn.edu> wrote:
> 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 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
> > _______________________________________________
> > 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/f691cf16/attachment-0001.html
More information about the cas-dev
mailing list