Re: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS?

From: Joe Kaplan \(MVP - ADSI\) (joseph.e.kaplan_at_removethis.accenture.com)
Date: 02/25/04

  • Next message: Novice: "Re: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS?" 
    Date: Tue, 24 Feb 2004 18:08:55 -0600

    Here is my understanding. Hopefully someone else will correct if I'm wrong
    or misleading.

    The short answer is that they all fall under CAS. I'm confused where you
    say all three permission classes as there are many more than three.

    What I think you are talking about is the difference between
    PrincipalPermission and the rest of the permissions. This is taken from the
    help on the topic: 

    ----
Unlike most other permissions, PrincipalPermission does not extend
CodeAccessPermission. It does, however, implement the IPermission interface.
This is because PrincipalPermission is not a code access permission; that
is, it is not granted based on the identity of the executing assembly.
Instead, it allows code to perform actions (Demand, Union, Intersect, and so
on) against the current user identity in a manner consistent with the way
those actions are performed for code access and code identity permissions.
----
This permission often gets confused with regular Windows role-based
security.  PrincipalPermission operates on the IPrincipal interface, which
is a .NET managed code concept.  It gets confusing because there are both
Windows and non-Windows implementations of IPrincipal (WindowsPrincipal and
GenericPrincipal for example), so sometimes it behaves like Windows security
and sometimes it does not.  It all depends on how the current principal got
assigned to the currently executing thread.  In a Windows Forms or Console
application, this is determined by what SetPrincipalPolicy is set to on the
current AppDomain.  In ASP.NET, this depends on what Context.User has been
set to which in turn depends on the authentication mode ASP.NET is in.
The big important difference though is the one stated in the documentation.
The evidence is based on the current thread principal, not on the current
assembly.
Note that Windows security is always in use by the OS, regardless of the CAS
settings.  That is to say that you can only access resources that Windows
will allow you to based on your current token-based security context.  This
is independent of CAS.  Thus, CAS can't grant you access to resources that
Windows prevents you from accessing, but CAS can further restrict your code
and provide protection for resources that Windows does not secure with an
ACL.
Hopefully this helps answer some of your questions.
Joe K.
"Novice" <6tc1ATqlinkDOTqueensuDOTca> wrote in message
news:9384B26B-312C-4321-A85F-34FDB069BC86@microsoft.com...
> Sorry to repost, I'm in somewhat of a desperate situation and I have found
that often people will be less inclined to try to assist on a posting if it
already has a reply and/or the post is asking a lot of questions.  In my
previous post someone just posted an agreement comment - as opposed to
answers to my questions.  Anyway, in the hopes of making the response to my
post less onerous - I will just ask one of my questions:
> Do all three permission classes (Identity Permission, Code Access
Permission and Role Based Permission) fall under CAS?
>
> And then if you are feeling ambitious, please feel free to tackle some of
the other questions in my original post (see below).
> ---------------------------------------------------
> Hi, I've done some reading on Microsoft .NET security and am a little
confused on the relationship between Code Access Security, Evidence Based
Security, Code Access Permission, Role Based Permission, Declarative and
Imperative Security Statements, etc.
>
> Here is my current understanding:
>
> Code Access Security is access based on the identity of the code not the
user running it (if this is true, then only the Identity Permission Code
Access Permission should fall under CAS - i.e. role-based security shouldn't
be a part of CAS).  Protected operations in CAS are file I/O, access to the
registry, etc.  CAS is being used when an assembly's evidence is examined
and a set of configurable rules (security policy) are applied to determine a
code's permissions.
>
> There are three types of "permission classes" (I'm quoting "permission
classes" because of confusion of the word permission in both Identity
Permission and Role-Based Permission):
> Identity Permission, Code Access Permission and Role Based Permission
>
> Permission objects of the above types are assigned to an assembly based on
its evidence and the security policy when the assembly is loaded into the
CLR.  All three "permission classes" fall within the domain of CAS or do
only Code-Access Permissions and Identity Permissions fall within the domain
of CAS???????  It seems likely to me that since you can enforce CAS using
all of the "permission classes" then all three "permission classes" fall
under the domain of CAS.  However, the statement:
> "Code Access Security is access based on the identity of the code not the
user running it "
> doesn't seem in agreement with that.
>
> -----------------------------
> --Identity Permission --
> amounts to the values of host evidence associated with an assembly.  To me
it makes little sense to call this Identity Permission, since they are just
values of the evidence of an assembly and regardless of any of the values of
the evidence, the permissions granted to an assembly are based on the
evidence AND the security policy - I could set up my security policy not to
give any permissions to evidence of any type.
>
> --Code-Access Permission-- 
> amounts to all the different types of permissions that can be granted to
an assembly - file access, network access, etc.  This makes sense, since
these are actual permissions - rights to do certain things.
>
> --Role-Based Permission--
> are the values associated with the user id and their role(s) (i.e. the
Principal)????  Again this is confusing, these aren't permissions, these are
merely values that represent the user whose account is being used to execute
the assembly (yes, users can be impersonated and thus be executed as if the
active user were the one being impersonated, but I'm trying to keep this as
simple as possible).
> -----------------------------
> Evidence-Based security is the security you get from using Identity
Permissions????  This is a term that was used in a microsoft document - so I
didn't just invent it.
> -----------------------------
> Imperative and Declarative Permission Requests or
> Imperative and Declarative Permission Styles or
> Imperative and Declarative Security Statements are ways of requesting that
the current assembly (its evidence) and/or user and/or granted permissions
(by CLR - using evidence and security policy) have certain "permissions".
Can Declarative Security Statements make use of all of the permission
classes?  I.E. can I specify that the access to the C drive is restricted
to:
> - a particular user or a user belonging to a particular role (i.e.
role-based permission)
> - an assembly that has access to the entire file system (as granted by the
CLR using evidence and security policy)  (i.e. code-access permission)
> - an assembly that has an assembly evidence object of type Developer (this
would be a customized evidence object) with the name "John Smith" (yes I'm
aware this is easily falsified)  (i.e. identity-based permission).
> -----------------------------
>
> Can someone try to sift through the information I've stated above and
confirm/deny the questions and change any inaccuracies.
>
> Thanks,
> Novice
>
  • Next message: Novice: "Re: Do all three permission classes (Identity Permission, Code Access Permission and Role Based Permission) fall under CAS?"

    Relevant Pages