Hi Marvin,
I've been doing some research into the possibility of implementing
Membership and Role support around CAS. The problem I've run into with
implementing a RoleProvider has to do with the fact that the interface
implies a view into the backend role store beyond the data in the
assertions. The assertions in a CAS ticket would let the app know the
roles applicable to the user associated with the CAS ticket, but that
isn't enough information to satisfy the interface.
// Can't be implemented on read-only providers
void AddUsersToRoles(string[] usernames, string[] roleNames);
void CreateRole(string roleName);
bool DeleteRole(string roleName, bool throwOnPopulatedRole);
void RemoveUsersFromRoles(string[] usernames, string[] roleNames);
// Can't be implemented without a list of the entire set of Roles
string[] GetAllRoles();
bool RoleExists(string roleName);
// Can't be implemented without a mapping of all {user, role}'s
string[] FindUsersInRole(string roleName, string usernameToMatch);
string[] GetRolesForUser(string username);
string[] GetUsersInRole(string roleName);
bool IsUserInRole(string username, string roleName);
I'm thinking that the best approach to RoleProvider support in CAS is to
use a Role provider that accesses the back-end data store directly
(i.e., goes to the source that the CAS server is using to generate the
assertions). For instance, an LdapRoleProvider or a SqlRoleProvider.
As suggested by Dianne Asis, we could also/alternatively implement the
IsInRole method of the ICasPrincipal to return the assertions. I've
been reading up on it a little bit but haven't had time to process it
all yet.
-ScottH
> -----Original Message-----
> From: Marvin Addison [mailto:[email protected]]
> Sent: Monday, March 29, 2010 9:16 AM
> To: [email protected]
> Subject: Re: [cas-dev] Implementation of authorization/role tag in
> DotNetCasClient.dll
>
> My recommendation is for a RoleProvider that is backed by the CAS
> assertion. This is the strategy used by both the Java CAS client and
> the Spring Security CAS client, so it has a couple sound precedents.
> I'm not against providing some sort of role-awareness in the CAS
> principal, but allowing pluggable role providers is a more modular
> approach in general. It would facilitate use cases where an
> application wants only CAS authentication with authorization performed
> elsewhere; for example a application-specific SQL Server database.
>
> M
>
> --
> 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-dev
--
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-dev
