RESTful CAS API

[scott_battaglia]

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

[Smith, Matt]

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?

  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.

</hat>

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

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]

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

[Smith, Matt]

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

[scott_battaglia]

I suppose I should put more examples up ;-)

On Wed, Apr 23, 2008 at 1:01 PM, Smith, Matt <matt.smith@...> 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@...>
> 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

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

[Earl Fogel]

Scott,

It looks good.  Two things, though:

  - Should there be a logout url?

  - You use both /cas/tickets and /cas/ticket.  That seems confusing.

Earl Fogel
Information Technology Services  phone: [phone]
University of Saskatchewan       email: earl.fogel@...
--
On Wed, 23 Apr 2008, 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

[scott_battaglia]

On Wed, Apr 23, 2008 at 4:56 PM, Earl Fogel <earl.fogel@...> wrote:

Scott,

It looks good.  Two things, though:

 - Should there be a logout url?

Good call.  I just added a way to delete a TGT which would be the equivalent.  It uses the HTTP DELETE method.  I haven't defined the response codes yet.

 - You use both /cas/tickets and /cas/ticket.  That seems confusing.

Good catch.  My left hand is overzealous when it comes to typing ;-).  The extra "s" has been removed.
 
-Scott

Earl Fogel
Information Technology Services  phone: [phone]
University of Saskatchewan       email: earl.fogel@...
--

On Wed, 23 Apr 2008, 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

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