[cas-dev] REST and SAML

[J. David Beutel]

It looks like CAS supports REST now (3.3), while the SAML discussion is 
for CAS 4 (notwithstanding what SAML support CAS already has).  Also, 
the intentions I've heard are to maintain backwards compatibility, not 
to discontinue support for the older protocols.

Cheers,
11011011


David Whitehurst wrote:
> I'm confused now.  Why would CAS support REST (very simple) and SAML?
> And, if CAS supports many different protocols, doesn't this introduce
> the chance for security issue? Wow! I see now that this is very tough
> when different institutions have very different solutions.  As a
> community though I would think that everyone does eventually want a
> secure and common solution.
>
> And, if e.g. the CAS server and clients fell in line or agreed to SAML
> as the only protocol in the future, wouldn't REST have to be
> discontinued entirely?
>
> I see the simplicity of REST and the server-to-client possibilities,
> but I still think that SAML adoption could rule out all other
> authentication communication languages eventually and then provide a
> very secure or fail-proof solution outside of someone just knowing
> someone else's credentials.
>
> Please comment on the REST vs. SAML idea?
>
> Thanks,
>
> David
> On 10/30/08, David Whitehurst <dlwhitehurst at gmail.com> wrote:
>   
>> Using the REST design here:
>>
>>  http://www.ja-sig.org/wiki/display/CASUM/RESTful+API
>>
>> Does this mean that SAML would replace e.g. an LDAP authenticator
>> specified in a deployerConfigContext.xml and require some SAML client
>> at the server holding the user credentials?  Or, would SAML be used to
>> send and return the calls to the CAS server only?
>>
>> I've been discussing the need for a black-box authentication interface
>> i.e. any authentication protocol on the input and any protocol on the
>> output.  If a single protocol were used for these communications you
>> could assure quality, consistency, and security in all using
>> implementations.  I'm not sure if SAML is a fit for this but a single
>> language would be beneficial.
>>
>> I firmly believe that this problem should have a resolution and an
>> end. You give or share the code for the resolution and the "only" code
>> that users/developers don't have are the cryptographic pieces.
>>
>> David
>>
>>     
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>