Thanks for the excellent and thorough explanation on the safety of attributes.

Let's say I was using Grouper to manage entitlements, where I'm
granting users access to certain applications.  Would this entitlement
information be passed in the attributes, which then get passed to the
applications, so that the applications know to grant this user access
to itself?

Thanks again,
Bradford

On Tue, Jan 17, 2012 at 4:17 PM, Andrew Petro <[email protected]> wrote:
> Bradford,
>
> This depends upon what you mean by "safe".
>
> Are CAS-vended user attributes spoofable?  No.  Attributes are vended in 
> response to a ticket validation request.  This is a service-to-service call 
> from the relying party to the CAS server.  The identity of the CAS server is 
> authenticated, and the transport layer secured, by virtue of the CAS server's 
> SSL certificate.  To the extent that you trust SSL certificates, this 
> attribute vending is safe.  To the extent that you don't trust SSL 
> certificates, the entire Web is unsafe.
>
> However, as I like perhaps too much to point out: While the CAS *server* is 
> authenticated in a ticket validation request and therefore in attribute 
> release (whether the attributes are released by the ships-in-CAS SAML 1.1 
> response or by the oft-added-to-serviceValidate customization of the CAS 
> server ticket validation response), the CAS *client* *isn't* authenticated.  
> The service ticket passed through the browser before it got to the 
> application that's validating it.  The service parameter on the ticket 
> validation request doesn't authenticate the requesting service, it just helps 
> a legitimate requesting service to avoid accidentally accepting a CAS ticket 
> intended for someone else.  The service ticket doesn't authenticate the 
> requesting service, it authenticates the end user.
>
> So is there a risk of a user asserting an "access_level" to which they're not 
> entitled?  No.  Is there a risk of CAS releasing "access_level" to a service 
> that's not entitled to see that attribute or to the end user himself?  Yes, 
> for a nuanced understanding of "risk".
>
> I'm not sure I have a "usually" for how roles and entitlements within 
> applications work, but lately in general I'm a big fan of Grouper as a good, 
> free and open source tool for managing user attributes, roles, permissions, 
> groups, with strong delegation capabilities.  Grouper is more of a "LDAP 
> wasn't featureful and usable enough" rather than an "LDAP is overkill" 
> solution, so it may be way, way more than you're looking for.  However, 
> there's some chance that you'd be happier implementing Grouper than writing 
> your own user management app.  I suggest giving it a look.  It has web 
> services and client software libraries for integrating reliance upon Grouper 
> into applications.
>
> http://www.internet2.edu/grouper/
>
> Kind regards,
>
> Andrew
>
>
>
>
> On Jan 17, 2012, at 3:04 PM, bradford wrote:
>
>> Maybe a stupid question, but I haven't spent time trying to figure out
>> how CAS works.  Is it safe to pass something like an "access_level" in
>> the extra attributes?
>>
>> Also, how do you guys usually assign people to applications?  I have a
>> user management app I'm writing (LDAP just seems overkill).  I'm
>> thinking of assigning users to applications at this level.  Then
>> within each application, assign them to roles.  Is this how you guys
>> usually do this?
>>
>> Thanks,
>> Bradford
>>
>> --
>> You are currently subscribed to [email protected] as: 
>> [email protected]
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
> --
> You are currently subscribed to [email protected] as: 
> [email protected]
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to