role-based security and ActiveDirectory

[Joe Kaplan]

Ok, something weird is going on then.

If the translated group names include OURDOMAIN\FOO_BAR but the
Context.User.IsInRole(@"OURDOMAIN\FOO_BAR") fails, then something is very
wrong. Both things use very similar code paths.

The other two points don't matter given that the group is actually IN the
security token. The check based on the group name should work fine. The
debug step was just to ensure the spelling of the name was correct so there
was no typo.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net

WindowsIdentity.GetCurrent is only the same as User.Identity when you have
impersonation enabled.

i see. i do have impersonation enabled -- enabling it and disabling
Anonymous Access seemed the only way to get ASP.NET apps to pickup
*anything* from AD. when these werent set my User.Identity.Name was
empty. by enabling impersonation and disabling anonymous
User.Identity.Name was filled w/ the currently-authenticated user.

The question is still whether or not Context.User.Identity belongs to the
group in question or not. If it does and the spelling is correct, then
Context.User.IsInRole *should* give you the behavior you want (as should
checks with the <authorization> element or PrincipalPermission.Demand
checks). It still isn't clear to me what the story is there from your
reply.

well, if my code is right, the answer is "Yes", the
Context.User.Identity does belong -- its translated group memberships
are exactly the same as the WindowsIdentity's groups. but it sounds
like this is expected as im using impersonation.

the code performing this check:

WindowsIdentity winIdentity2 = (WindowsIdentity)Context.User.Identity;

IdentityReferenceCollection usersGroups2 =
winIdentity2.Groups.Translate(System.Type.GetType
("System.Security.Principal.NTAccount"));

sb = new StringBuilder(200);

foreach (IdentityReference group in usersGroups2)
sb.Append(group.Value + "<br/>");

litGroups2.Text = sb.ToString();


.....there in the Literal i see my OURDOMAIN\FOO_BAR listed.


sm

 

[SpaceMarine]

Ok, something weird is going on then.

one thing to add -- would using the AzMan role manager muck anything
up? im using this for my app's custom roles. my assumption is i can
still use the AD roles for broad access limits, while using AzMan for
more granular custom access limits within the app:

<authentication mode="Windows" />

<authorization>
<!-- allow only group users.. not working
<allow roles="FOO_BAR"/>
<deny users="*"/>
<deny users="?"/> -->

<allow users="*" />
<deny users="?" />
</authorization>

<roleManager enabled="true"
defaultProvider="AzManRoleManager"
cacheRolesInCookie="true"
cookieName=".AppXRoles"
cookiePath="/"
cookieTimeout="30"
cookieRequireSSL="true"
cookieSlidingExpiration="true"
createPersistentCookie="false"
cookieProtection="All">
<providers>
<clear />
<add name="AzManRoleManager"
applicationName="AppX"
connectionStringName="azMan"
type="System.Web.Security.AuthorizationStoreRoleProvider,
System.Web, Version=2.0.0.0, Culture=neutral,
publicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>

 

[SpaceMarine]

   User.IsInRole(@"OURDOMAIN\FOO_BAR") or
   User.IsInRole("FOO_BAR") or

on another forum someone suggested i had to use Roles.IsUserInRole(),
like so:

Response.Write("in role: " + Roles.IsUserInRole("FOO_BAR") + "<br/

");

....but this is False as well. argh.


sm

 

[Joe Kaplan]

The AzMan role provider would make a significant difference here since it
will change the roles the user has to the mapped roles in the AzMan model
and not the AD roles. If you remove that role provider, you should get
successful checks against the AD-based role using the fully qualified name.

If you want to use the AD role in conjunction with AzMan, you should map it
to an AzMan role and then use the mapped AzMan role for your authorization
checks.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net

Ok, something weird is going on then.

one thing to add -- would using the AzMan role manager muck anything
up? im using this for my app's custom roles. my assumption is i can
still use the AD roles for broad access limits, while using AzMan for
more granular custom access limits within the app:

<authentication mode="Windows" />

<authorization>
<!-- allow only group users.. not working
<allow roles="FOO_BAR"/>
<deny users="*"/>
<deny users="?"/> -->

<allow users="*" />
<deny users="?" />
</authorization>

<roleManager enabled="true"
defaultProvider="AzManRoleManager"
cacheRolesInCookie="true"
cookieName=".AppXRoles"
cookiePath="/"
cookieTimeout="30"
cookieRequireSSL="true"
cookieSlidingExpiration="true"
createPersistentCookie="false"
cookieProtection="All">
<providers>
<clear />
<add name="AzManRoleManager"
applicationName="AppX"
connectionStringName="azMan"
type="System.Web.Security.AuthorizationStoreRoleProvider,
System.Web, Version=2.0.0.0, Culture=neutral,
publicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>

 

[SpaceMarine]

The AzMan role provider would make a significant difference here since it
will change the roles the user has to the mapped roles in the AzMan model
and not the AD roles.

i see. so by using the AzMan provider i wipe out any intrinsic AD
roles from the windows token...

is that also the case w/ the SQL Role Provider? im using the AzMan
because my apps have custom roles that we cant ask our AD admins to
manage. i chose AzMan because 1) its lighter & simpler than a
database. 2) can use MMC snap-in to manage in a jiffy (i also have a
web UI but that can be done for any provider)... its been pretty
painless thus far.

 If you remove that role provider, you should get
successful checks against the AD-based role using the fully qualified name.

WE HAVE A WINNER!! that works. also, looks like i dont need the domain
name in the Role string, just the group name.

If you want to use the AD role in conjunction with AzMan, you should map it
to an AzMan role and then use the mapped AzMan role for your authorization
checks.

this works perfectly. THANK YOU, JOE!!!


this mystery has been solved. book 'em, boys...

sm

 

[Joe Kaplan]

Glad that works. To summarize, the role providers "overwrite" existing role
data, so if you want some sort of a "merged" view of roles, you may have to
do a little extra work to achieve that. In your case using AzMan, probably
the best thing to do is map the Windows group to an AzMan role in the AzMan
configuration and then let the AzMan framework handle the transformation of
that data on the fly.

In the long run this approach is probably better anway because then the
AD-specific stuff is not coded in your app at all but is externalized in in
the AzMan configuration. This adds a bit more flexibility to the whole
system.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net

The AzMan role provider would make a significant difference here since it
will change the roles the user has to the mapped roles in the AzMan model
and not the AD roles.

i see. so by using the AzMan provider i wipe out any intrinsic AD
roles from the windows token...

is that also the case w/ the SQL Role Provider? im using the AzMan
because my apps have custom roles that we cant ask our AD admins to
manage. i chose AzMan because 1) its lighter & simpler than a
database. 2) can use MMC snap-in to manage in a jiffy (i also have a
web UI but that can be done for any provider)... its been pretty
painless thus far.

If you remove that role provider, you should get
successful checks against the AD-based role using the fully qualified
name.

WE HAVE A WINNER!! that works. also, looks like i dont need the domain
name in the Role string, just the group name.

If you want to use the AD role in conjunction with AzMan, you should map
it
to an AzMan role and then use the mapped AzMan role for your authorization
checks.

this works perfectly. THANK YOU, JOE!!!


this mystery has been solved. book 'em, boys...

sm