Bradford, Mostly, yes, if you were using Grouper to manage entitlements, you could configure CAS to read in those user attributes. You could configure CAS to release those attributes (and which attributes to release to which service). And then you could get at those attributes from services either via the ships-in-CAS SAML11 validation response or by customizing the serviceValidate response to include attributes (which it does not include ootb). And then, yes, the applications could use those attributes to determine whether to grant access to themselves.
If you're doing coarse-grained access control rather than fine-grained access control, you could consider implementing that at the CAS server level. Maybe CAS shouldn't let a user get a service ticket at all for a replying party that the user isn't entitled to access. In the details: CAS uses the PersonDirectory API to get user attributes. That ships with LDAP and JDBC support but not Grouper support as such. Grouper is able to provision LDAP, so you might go for an attribute query against Grouper-provisioned LDAP. Or you could implement a new PersonAttributeDAO against Grouper to get entitlements from Grouper within CAS's user attribute collection sub-system. And if you want to implement the coarse-grained access control at the CAS server layer, offhand, i'd suggest a new Action in the login web flow that checks the resolved Principal's attributes for the entitlements required to access the resolved RegisteredService. And, of course, enhancing the service registry to afford registration of what attributes (entitlements) should be required of supplicants seeking service tickets for that service. Kind regards, Andrew On Jan 18, 2012, at 9:39 AM, bradford wrote: > 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
