WindowsPrincipal m_roles, m_rolesTable, m_rolesLoaded question

[costasz]

We have these ASP.Net 1.1 apps that use ADS authentication. There was
a requirement to load ALL the roles for a particular user. We had used
reflection to get to the Principal's m_roles field to get them. Now,
we're running in ASP.Net 2.0 and I see that m_roles is null,
m_rolesTable is null and m_rolesLoaded is false. The Principal object
looks good to me otherwise. Any ideas?

Thanks

Costas

 

[Joe Kaplan]

This is what you get for using reflection against private members in
production code.

What you should do in .NET 2.0 is cast the Identity member to a
WindowsIdentity and access the Groups property. That will give you an
IdentityReferenceCollection containing the groups as SecurityIdentifier
objects. You can then use the Translate method on the collection class to
translate them to NTAccount objects and get the friendly names.

This method will also work going forward, since you will be using a
documented public interface.

Joe K.

 

[costasz]

Isn't it bizarre that the roles collection is not available as a read
only property?


Thanks


CZ

 

[Joe Kaplan]

It is an eternal mystery, although I'm sure there is a reason. Maybe D.
knows?

Joe K.

 

[Dominick Baier]

Well - it is available. just as SIDs.

Since it requires network roundtrips to translate SIDs to the "names" - it
makes sense to me to explicitly request the information...

 

[Joe Kaplan]

I think he was asking why there is no Roles property directly on IPrincpal,
only an IsInRole method. That's the impression that I got. Any clue?

Joe K.

 

[Dominick Baier]

because thats up to the implementation - that's at least the reason why it
is not part of IPrincipal.

You know that Windows auth is a little special - auth and authZ information
is packaged as one opaque blob (the token).

Well - there is a Groups property on WindowsIdentity (which makes sense if
you think about a WindowsIdentity as the managed wrapper for tokens).

But yeah - WindowsPrincipal could support this (maybe vnext

 

[Joe Kaplan]

I guess I too always thought it would be helpful if IPrincipal itself had
directly had a Roles property that returned some sort of read only
collection of strings. Presumably if it can handle the IsInRole question,
it must know the roles, right?

I guess I could see a few situations where enumerating the groups might be
very expensive vs. just checking for membership, but in practice, I haven't
really seen that to be the case.

I'm sure there must be a reason why the BCL guys decided not to include
this. It would be good to know why. Maybe it is in one of those giant Brad
Abrams Addison-Wesley books....

Joe K.

 

[Dominick Baier]

well - i think there is a difference between having such functionality in
a principal object and *enforcing* it - which would be the effect if they
added the Roles property to the IPrincipal interface.

RolePrincipal in ASP.NET e.g. has a GetRoles method.

So yes WindowsPrincipal could do a better job - but i don't think it should
be part of the interface.