Yes, thank you Andrew! Speaking of which, how do you add attribute release capabilities to the regular serviceValidate?
18 jan 2012 kl. 15:39 skrev bradford <[email protected]>: > 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 > -- 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
