.NET Roles

18 Apr 2005 2:56 PM

Oriane

Hi,

I'm trying to understand the underlying principles of the .NET roles
configuration.

What is clear to me is that we can map a thread/process Windows owner and
the IPrincipal, and then test the membership to Windows group:

private void method () {
    IPrincipal PR = Thread.CurrentPrincipal;
    if (PR.IsInRole (@"BUILTIN\Administrators")) {
         // Only an administrator can execute the code here

In that case, the IsInRole method is not to be rewrote.

The following code is (more or less) equivalent:
[PrincipalPermission(SecurityAction.Demand, Role=@"BUILTIN\Administrators")]

private void method () {

Does the "Permission "attribute code call the IsInRole method ?

____________________________________________________________________________
____________
However, if we need to handle with "applicative roles", can we derive a
class from IPrincipal and write our own IsInRole method ?
Are we compelled to map the process/thread owner with the Identity
associated to the IPrincipal ? I guess that the answer is no.

In that case, does the following code work:
[PrincipalPermission(SecurityAction.Demand, Role=@"BUILTIN\Administrators")]

private void method () {
?

Oriane

18 Apr 2005 4:22 PM

Joe Kaplan (MVP - ADSI)

Essentially yes, the PrincipalPermission and PrincipalPermissionAttribute
get the current IPrincipal from Thread.CurrentPrincipal and use it's
IsInRole method to perform this check.

Also notice that IPrincipal is an interface, which means that you can
implement your own role-based security. Having it integrate with Windows
security is great for some stuff, but in other instances you may not want
that. .NET gives you a lot of flexibility with this design.

Joe K.

Show quoteHide quote

"Oriane" <Ori***@Guermantes.com> wrote in message
news:OjpO9aCRFHA.164@TK2MSFTNGP12.phx.gbl...
> Hi,
>
> I'm trying to understand the underlying principles of the .NET roles
> configuration.
>
> What is clear to me is that we can map a thread/process Windows owner and
> the IPrincipal, and then test the membership to Windows group:
>
> private void method () {
>    IPrincipal PR = Thread.CurrentPrincipal;
>    if (PR.IsInRole (@"BUILTIN\Administrators")) {
>         // Only an administrator can execute the code here
>
> In that case, the IsInRole method is not to be rewrote.
>
> The following code is (more or less) equivalent:
> [PrincipalPermission(SecurityAction.Demand,
> Role=@"BUILTIN\Administrators")]
>
> private void method () {
>
>
> Does the "Permission "attribute code call the IsInRole method ?
>
> ____________________________________________________________________________
> ____________
> However, if we need to handle with "applicative roles", can we derive a
> class from IPrincipal and write our own IsInRole method ?
> Are we compelled to map the process/thread owner with the Identity
> associated to the IPrincipal ? I guess that the answer is no.
>
> In that case, does the following code work:
> [PrincipalPermission(SecurityAction.Demand,
> Role=@"BUILTIN\Administrators")]
>
> private void method () {
> ?
>
> Oriane
>
>