Security - Permissions Configuration

[Angelos Karantzalis]

Is there a way to set Permissions based on user roles by using some
configuration file for my application ?

I'm coming from a Java background, where that could very easily be
accomplished but although I've searched around MSDN I can't find a clear
answer to this ...

Thanks a lot guys,

Angel
O:]

[Henrik Nordgren]

Asp.net security is based on iis.

In IIS you can define users, groups etc, and then in your web.config file
you can enable "windows security" or manually enable/disable access for
certain groups.

if you want the entire asp.net app to run under another account than the
standard asp.net wp you can use impersonation.

Try some searches on msdn, they have excellent articles on all these subjects

yours
Henrik

"Angelos Karantzalis" wrote:

Is there a way to set Permissions based on user roles by using some
configuration file for my application ?

I'm coming from a Java background, where that could very easily be
accomplished but although I've searched around MSDN I can't find a clear
answer to this ...

Thanks a lot guys,

Angel
O:]

[Angelos Karantzalis]

What I want to get at is having CodeAccess permissions, based on the role of
my user. Not only on ASP.NET though, and definitely by using custom
IPrincipal implementations. I don't want just to restrict accesss to some
url pattern based on the current user :(

Thanks though,
Angel
O:]
"Henrik Nordgren" <He************@discussions.microsoft.com> wrote in
message news:CD**********************************@microsof t.com...

Asp.net security is based on iis.

In IIS you can define users, groups etc, and then in your web.config file
you can enable "windows security" or manually enable/disable access for
certain groups.

if you want the entire asp.net app to run under another account than the
standard asp.net wp you can use impersonation.

Try some searches on msdn, they have excellent articles on all these subjects
yours
Henrik

"Angelos Karantzalis" wrote:

Is there a way to set Permissions based on user roles by using some
configuration file for my application ?

I'm coming from a Java background, where that could very easily be
accomplished but although I've searched around MSDN I can't find a clear
answer to this ...

Thanks a lot guys,

Angel
O:]

[UAError]

"Angelos Karantzalis" <ak**********@agiltech.gr> wrote:

What I want to get at is having CodeAccess permissions, based on the role of
my user. Not only on ASP.NET though, and definitely by using custom
IPrincipal implementations. I don't want just to restrict accesss to some
url pattern based on the current user :(

Thanks though,
Angel
O:]

Code Access Security (CAS) and Role-Based Security (RBS) are
totally independent concepts.

CAS is concerned with the identity and origin of the code
and further restricts any permissions that the Windows
User/Account may already have.

RBS is concerned with the user of your application - it may
coincide with the Windows User and his/her membership in
Windows Groups (i.e. roles), but RBS can also be independent
of Windows Security total, centered on your software.

Designing Application-Managed Authorization
http://msdn.microsoft.com/library/de...html/DAMAZ.asp

NET Framework Developer's Guide Introduction to Role-Based
Security
http://msdn.microsoft.com/library/de...edsecurity.asp

..NET Framework Developer's Guide Principal and Identity
Objects
http://msdn.microsoft.com/library/de...ityobjects.asp

To (re)use Windows Users and Groups use WindowsIdentity and
WindowsPrincipal.

NET Framework Developer's Guide Creating WindowsIdentity and
WindowsPrincipal Objects
http://msdn.microsoft.com/library/de...palObjects.asp
NET Framework Class Library WindowsIdentity Class
http://msdn.microsoft.com/library/de...classtopic.asp
..NET Framework Class Library WindowsPrincipal Class
http://msdn.microsoft.com/library/de...ClassTopic.asp

To implement your own "basic" RBS use GenericIdentity and
GenericPrincipal.

..NET Framework Developer's Guide Creating GenericPrincipal
and GenericIdentity Objects
http://msdn.microsoft.com/library/de...palObjects.asp
..NET Framework Class Library GenericIdentity Class
http://msdn.microsoft.com/library/de...ClassTopic.asp
..NET Framework Class Library GenericPrincipal Class
http://msdn.microsoft.com/library/de...ClassTopic.asp

If you need a more sophisticated RBS, e.g. your roles imply
a certain trust heirarchy, then you need to implement some
custom classes implementing the IIdentity and IPrincipal
inferfaces.

..NET Framework Class Library IIdentity Interface
http://msdn.microsoft.com/library/de...ClassTopic.asp
NET Framework Class Library IPrincipal Interface
http://msdn.microsoft.com/library/de...ClassTopic.asp

For an overview of CAS

..NET Framework Developer's Guide Code Access Security
http://msdn.microsoft.com/library/de...sssecurity.asp

[Angelos Karantzalis]

Well, that was a very informative set of links there, but still, what I need
to do is ( or should ) be very simple.

I've already got my custom GenericPrincipal subclasses, that get assigned
roles from my application.

What I need to do now is this. Inside the code of some business objects, I
want to be checking (demanding) a certain permission - NOT a
PrincipalPermission though. I don't want the class having to know the
users/groups that can use it, and I don't want the class to have to read
some external configuration file itself, to ask for the right
PrincipalPermission.

I want to learn how the system assigns permissions to users/groups in
general, and whether I can customize that in some sort of declerative
manner, just like I can do in Java using policy files.

Now, that shouldn't be too hard, and it should be available as .NET
functionality. But where ???

Angel
O:]
"UAError" <nu**@null.null> wrote in message
news:33********************************@4ax.com...

"Angelos Karantzalis" <ak**********@agiltech.gr> wrote:

What I want to get at is having CodeAccess permissions, based on the role ofmy user. Not only on ASP.NET though, and definitely by using custom
IPrincipal implementations. I don't want just to restrict accesss to some
url pattern based on the current user :(

Thanks though,
Angel
O:]
Code Access Security (CAS) and Role-Based Security (RBS) are
totally independent concepts.

CAS is concerned with the identity and origin of the code
and further restricts any permissions that the Windows
User/Account may already have.

RBS is concerned with the user of your application - it may
coincide with the Windows User and his/her membership in
Windows Groups (i.e. roles), but RBS can also be independent
of Windows Security total, centered on your software.

Designing Application-Managed Authorization

http://msdn.microsoft.com/library/de...us/dnbda/html/
DAMAZ.asp
NET Framework Developer's Guide Introduction to Role-Based
Security
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconintroductiontorole-basedsecurity.asp
.NET Framework Developer's Guide Principal and Identity
Objects
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconprincipalidentityobjects.asp
To (re)use Windows Users and Groups use WindowsIdentity and
WindowsPrincipal.

NET Framework Developer's Guide Creating WindowsIdentity and
WindowsPrincipal Objects
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconCreatingWindowsIdentityWindowsPrincipalObject s.asp NET Framework Class Library WindowsIdentity Class
http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfsystemsecurityprincipalwindowsidentityclassto pic.asp .NET Framework Class Library WindowsPrincipal Class
http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfSystemSecurityPrincipalWindowsPrincipalClassT opic.asp
To implement your own "basic" RBS use GenericIdentity and
GenericPrincipal.

.NET Framework Developer's Guide Creating GenericPrincipal
and GenericIdentity Objects
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconCreatingWindowsIdentityWindowsPrincipalObject s.asp .NET Framework Class Library GenericIdentity Class
http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfSystemSecurityPrincipalGenericIdentityClassTo pic.asp .NET Framework Class Library GenericPrincipal Class
http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfSystemSecurityPrincipalGenericPrincipalClassT opic.asp
If you need a more sophisticated RBS, e.g. your roles imply
a certain trust heirarchy, then you need to implement some
custom classes implementing the IIdentity and IPrincipal
inferfaces.

.NET Framework Class Library IIdentity Interface
http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfSystemSecurityPrincipalIIdentityClassTopic.as p NET Framework Class Library IPrincipal Interface
http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfSystemSecurityPrincipalIPrincipalClassTopic.a sp
For an overview of CAS

.NET Framework Developer's Guide Code Access Security

http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconcodeaccesssecurity.asp

[Peer Reynders]

"Angelos Karantzalis" <ak**********@agiltech.gr> wrote:

Well, that was a very informative set of links there, but still, what I need
to do is ( or should ) be very simple.

I've already got my custom GenericPrincipal subclasses, that get assigned
roles from my application.

What I need to do now is this. Inside the code of some business objects, I
want to be checking (demanding) a certain permission - NOT a
PrincipalPermission though. I don't want the class having to know the
users/groups that can use it, and I don't want the class to have to read
some external configuration file itself, to ask for the right
PrincipalPermission.

I want to learn how the system assigns permissions to users/groups in
general, and whether I can customize that in some sort of declerative
manner, just like I can do in Java using policy files.

Now, that shouldn't be too hard, and it should be available as .NET
functionality. But where ???

Angel
O:]

And why exactly would make such an assumption?

And why would you expect anyone in a dotNet usenet group to
know what a "Java Policy" file is? (Other platforms solve
security issues in different ways).

Anyway, I took a look at
http://mindprod.com/jgloss/policyfile.html

And all the examples I saw were similar to Code Access
Security (CAS; concerns itself with the identity and origin
of the code, not the identity the user) not RBS.

"JDK 1.2+ file that controls what programs, weblets and
Applets are allowed to do."

Even sounds like CAS.

CAS is configured through the .NET Framework Configuration
Tool or CasPol.exe (and has got nothing to do with IIdentity
or IPrincipal).

NET Framework Developer's Guide: Code Access Security
http://msdn.microsoft.com/library/de...sssecurity.asp
Chapter 8 – Code Access Security in Practice
http://msdn.microsoft.com/library/de...l/thcmch08.asp
How To: Use Code Access Security Policy to Constrain an
Assembly
http://msdn.microsoft.com/library/de...htcode_acc.asp

[Angelos Karantzalis]

Perhaps the question would be "why would anyone in a .NET group ever want to
do anything out of the ordinary ?".

I'm sorry, that was nasty of me. But since there could be a case when you
might want to merge CAS with RBS, there must be a way to do that in a
declerative manner, and not have to program half a framework to do it :(

Angel
O:]
"Peer Reynders" <pe***********@sympatico.ca> wrote in message
news:ck********************************@4ax.com...

"Angelos Karantzalis" <ak**********@agiltech.gr> wrote:

Well, that was a very informative set of links there, but still, what I needto do is ( or should ) be very simple.

I've already got my custom GenericPrincipal subclasses, that get assigned
roles from my application.

What I need to do now is this. Inside the code of some business objects, Iwant to be checking (demanding) a certain permission - NOT a
PrincipalPermission though. I don't want the class having to know the
users/groups that can use it, and I don't want the class to have to read
some external configuration file itself, to ask for the right
PrincipalPermission.

I want to learn how the system assigns permissions to users/groups in
general, and whether I can customize that in some sort of declerative
manner, just like I can do in Java using policy files.

Now, that shouldn't be too hard, and it should be available as .NET
functionality. But where ???

Angel
O:]
And why exactly would make such an assumption?

And why would you expect anyone in a dotNet usenet group to
know what a "Java Policy" file is? (Other platforms solve
security issues in different ways).

Anyway, I took a look at
http://mindprod.com/jgloss/policyfile.html

And all the examples I saw were similar to Code Access
Security (CAS; concerns itself with the identity and origin
of the code, not the identity the user) not RBS.

"JDK 1.2+ file that controls what programs, weblets and
Applets are allowed to do."

Even sounds like CAS.

CAS is configured through the .NET Framework Configuration
Tool or CasPol.exe (and has got nothing to do with IIdentity
or IPrincipal).

NET Framework Developer's Guide: Code Access Security

http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconcodeaccesssecurity.asp Chapter 8 - Code Access Security in Practice
http://msdn.microsoft.com/library/de...us/dnnetsec/ht
ml/thcmch08.asp How To: Use Code Access Security Policy to Constrain an
Assembly
http://msdn.microsoft.com/library/de...us/dnnetsec/ht
ml/htcode_acc.asp

[Angelos Karantzalis]

On second read of your post, I can see better where you're coming from...

Well, the definition you found was a bit "constrained" ... you CAN assign
permissions to principals and not only codebases with Java Policy Files.

I'd think that CAS sound a bit like a small part of Java Authentication and
Authorisation (JAAS) :D

Consider the following:

You're building an application, which supports services in the form of
dynamically downloaded plugins. You can expect that more than one users will
be using the same installation. Some of those plugins though, need the user
has special authorization (role) to run, others don't. To complicate the
matter a bit further, you can execute the plugin under a "login domain" -
you have multiple login domains in the app, and each time you try to do
anything, you do it under a login domain, a "context" if you will ... , and
the plugins are shared between domains. But you need different roles to use
them under each domain ...

Now, I need a way to assign Code Access ( or Data Access, or whatever
Access ) permissions - at runtime - based on the roles of my user, under the
specific login domain she's currently using ( mind you .. login domains are
just a click on a drop-down list of domains for the user ! ). So ? There
simply MUST be a way to couple CAS and RBS, because it makes sence !!! I
can't believe that MS would leave something like that out of the framework,
when it's trying desperately to match - and possibly exceed - the Java
functionality.

... but most importantly ... sooner or later with the advent of C#, you can
expect to find much more Java people invading your "turf", bringing with
them a whole new mentality where specialization is actually ... BAD !!!
Volvos & SAABs are different cars in behavior, but you can drive them both,
and expect more-or-less the same basic "services" from both, don't you ?

Open your mind a bit ... ;]

Angel
O:]

"Peer Reynders" <pe***********@sympatico.ca> wrote in message
news:ck********************************@4ax.com...

"Angelos Karantzalis" <ak**********@agiltech.gr> wrote:

Well, that was a very informative set of links there, but still, what I needto do is ( or should ) be very simple.

I've already got my custom GenericPrincipal subclasses, that get assigned
roles from my application.

What I need to do now is this. Inside the code of some business objects, Iwant to be checking (demanding) a certain permission - NOT a
PrincipalPermission though. I don't want the class having to know the
users/groups that can use it, and I don't want the class to have to read
some external configuration file itself, to ask for the right
PrincipalPermission.

I want to learn how the system assigns permissions to users/groups in
general, and whether I can customize that in some sort of declerative
manner, just like I can do in Java using policy files.

Now, that shouldn't be too hard, and it should be available as .NET
functionality. But where ???

Angel
O:]
And why exactly would make such an assumption?

And why would you expect anyone in a dotNet usenet group to
know what a "Java Policy" file is? (Other platforms solve
security issues in different ways).

Anyway, I took a look at
http://mindprod.com/jgloss/policyfile.html

And all the examples I saw were similar to Code Access
Security (CAS; concerns itself with the identity and origin
of the code, not the identity the user) not RBS.

"JDK 1.2+ file that controls what programs, weblets and
Applets are allowed to do."

Even sounds like CAS.

CAS is configured through the .NET Framework Configuration
Tool or CasPol.exe (and has got nothing to do with IIdentity
or IPrincipal).

NET Framework Developer's Guide: Code Access Security

http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconcodeaccesssecurity.asp Chapter 8 - Code Access Security in Practice
http://msdn.microsoft.com/library/de...us/dnnetsec/ht
ml/thcmch08.asp How To: Use Code Access Security Policy to Constrain an
Assembly
http://msdn.microsoft.com/library/de...us/dnnetsec/ht
ml/htcode_acc.asp

[UAError]

"Angelos Karantzalis" <ak**********@agiltech.gr> wrote:

On second read of your post, I can see better where you're coming from...

Well, the definition you found was a bit "constrained" ... you CAN assign
permissions to principals and not only codebases with Java Policy Files.

I'd think that CAS sound a bit like a small part of Java Authentication and
Authorisation (JAAS) :D

Consider the following:

You're building an application, which supports services in the form of
dynamically downloaded plugins. You can expect that more than one users will
be using the same installation. Some of those plugins though, need the user
has special authorization (role) to run, others don't. To complicate the
matter a bit further, you can execute the plugin under a "login domain" -
you have multiple login domains in the app, and each time you try to do
anything, you do it under a login domain, a "context" if you will ... , and
the plugins are shared between domains. But you need different roles to use
them under each domain ...

Now, I need a way to assign Code Access ( or Data Access, or whatever
Access ) permissions - at runtime - based on the roles of my user, under the
specific login domain she's currently using ( mind you .. login domains are
just a click on a drop-down list of domains for the user ! ). So ? There
simply MUST be a way to couple CAS and RBS, because it makes sence !!! I
can't believe that MS would leave something like that out of the framework,
when it's trying desperately to match - and possibly exceed - the Java
functionality.

.. but most importantly ... sooner or later with the advent of C#, you can
expect to find much more Java people invading your "turf", bringing with
them a whole new mentality where specialization is actually ... BAD !!!
Volvos & SAABs are different cars in behavior, but you can drive them both,
and expect more-or-less the same basic "services" from both, don't you ?

Open your mind a bit ... ;]

Angel
O:]
Don't ask of others what you aren't willing to do yourself
.... ;]

I suspect that both SUN and Microsoft simply applied
different philosophies to the implementation of security.
Maybe SUN determined that the Java-VM had to be responsible
for ANY aspect of security, especially as they ultimately
have NO control over OS platform security.

Microsoft has FULL control over OS platform security and
they chose not to duplicate security features that were
already present in the OS (ignoring flavours of Win9x and
below).

Windows Security can protect most platform resources with
Access Control Lists (ACLs), so (at least for the time
being) .NET does not duplicate Windows Security.

CAS and RBS cannot grant the user privileges and access
rights he or she doesn't already have. If a .NET application
tries to do something the user isn't entitled to do by
virtue of the access granted to the user account and
memberships in Windows Groups, the OS lets .NET know and
..NET will propagate an exception to the applications
Application Domain.

If you want to prevent an exception, you have the option of
using WindowsPrincipal.IsInRole to check whether the current
user belongs to a Windows group that you assume or know to
have access to the resource.

While privileges are associated with an account or windows
group, access rights are not - access rights are associated
with the resource being protected. Currently you need to use
ummanaged code to read and manipulate ACLs (that will
probably change in the future).

RBS is present to enable you to protect resources that your
application creates and cannot be protected by the OS
platform.

CAS is there to further refine the level of trust that you
have in code of a specific identity or origin.

The only way you can have an application do things the user
isn't allowed to do, is by actually running the application
in the security context of a more privileged account. That
practice however exposes you to a potential "Elevation of
Privilege" attack - this practice has been actively
discouraged since Microsoft's security pushes starting in
late 2001 as it violates the "Principle of Least Privilege".

In fact the internet has grown so "hostile" that the current
best practice is to run an application in a "least
privilege" context which impersonates the user only in
sections of code where the application needs gain privileges
that USER has.

Now if you are interested in Windows Security as it affects
..NET (rather than .NET Security) have a look at Keith
Brown's Book on-line.

"The .NET Developer's Guide to Windows Security"
http://pluralsight.com/wiki/default....eBook.HomePage

when it's trying desperately to match - and possibly exceed - the Java
functionality.

And again, you are making assumptions. They aren't.

There is no denying they snoozed when they underestimated
the impact that Java would have. Probably because most
people thought of Java as a langange, not a platform. So
when the door slammed on a SUN/Microsoft alliance, they had
to do something.

"Never engage an enemy on their own terms"

SUN et al had made significant progress so if they pitched
..NET against the Java-VM they could at best hope for a tie,
and that would be a faint hope.

So instead, they are using .NET as a catalyst to transform
their server-line to something that may be able to leave
Intel-based hardware platforms in the future, so in fact
..NET is a key component of Windows struggle against the
*nixes.

For the short term .NET focuses on distributed architectures
simply because the market for servers that "scale up" is
dominated by the *nixes. So Windows/.NET is going after the
"scale out" server market - which suits corporate mentality;
buy a few cheap servers this financial year, a few more the
next (the fact that this requires a team of highly skilled
(and expensive) administrators and developers to pull off is
material for yet another debate).

Expect to see some timebased server-licensing/maintenance
fee options that eliminate upfront cost of the Server OS and
are somewhat competitve to the then better understood
cost-of-ownership of Open Source OSs; this also fits the
corporate "financial year" mentality even though it will
increase the total cost of ownership over the products
lifetime (car-leases took off; why not this?).

Java and .NET will both stick around and developers will
have to live with it.
Windows and *nixes will also stick around and administrators
will have to live it.
Meanwhile the battle for marketshare rages on ...

[Angelos Karantzalis]

... I'll just have to do it myself then :D

[UAError]

"Angelos Karantzalis" <ak**********@agiltech.gr> wrote:

.. I'll just have to do it myself then :D

You're still in the danger of reinventing the wheel and
,worse, creating yet another application that requires
administrator privileges to run.
You're building an application, which supports services in the form of
dynamically downloaded plugins.
OK standard users are often denied the privilege to
"install" anything. A downloaded .NET assembly can be
downloaded and run in a "sandbox" but it still is configured
by CAS to the "Internet" Permission set and that doesn't
allow much.

You can however get the "client" too install code groups and
permission sets that match your code through membership
conditions to grant your assembly(ies) permissions beyond
the ones found in the "Internet" permission set. However
these must at least be present on the Enterprise level
Security policy (marked as LevelFinal) which can only be
done by an administrator. If its not marked as "LevelFinal",
the code groups/permission sets will also have to be present
on the User level Security Policy and Machine level Security
Policy.

But ultimately CAS cannot grant more rights than the user
already has under Windows.
You can expect that more than one users will
be using the same installation. Some of those plugins though, need the user
has special authorization (role) to run, others don't.
This is were you are not specific enough - (A) does your
application not want them to have access to an application
feature or (B) is there a platform resource that the user
does not have access too.

if (A) then you need to implement you own RBS most likely
with GenericIdentity and GenericPrincipal.

if (B) let Windows Security handle it; .NET will generate an
exception. If you want to be able to disable features in the
absence of access rights use WindowsPrincipal.IsInRole - the
Windows Group can be one you created on the machine or in
the domain for the purposes of your application - existing
users will then simply have to be assigned windows group
memberships pertinent to your application.
To complicate the
matter a bit further, you can execute the plugin under a "login domain" -
you have multiple login domains in the app, and each time you try to do
anything, you do it under a login domain, a "context" if you will ... ,
This is were you lose me - I think there's breakdown of
communication here. To me a username that is valid in
multiple network domains still are multiple distinct
"users". I don't know what concept you are trying to convey
with "login domains".

However under windows it is possible for a windows user to
run an application as a different user and have certain
parts of the application run as a differrent user through
the use of impersonation (provided the necessary credentials
are present).

But even that privilege can be denied. To impersonate you
have to have the
SeTcbPrivilege "Act as part of the operating system"
(TCB = Trusted Computing Base)

privilege. This has been changed in .NET Server 2003 which
has:
SeImpersonatePrivilege "Impersonate a client after
authentication"

to close that vulnerabilty.
and
the plugins are shared between domains. But you need different roles to use
them under each domain ...

[Angelos Karantzalis]

Yeah, I can understand that the wording is a bit messy & confusing.

In simple terms:

1. We have an application "base", where it provides some GIS-related UI
functionality ( It can do "stuff" on a Map, displayed in 2D or 3D ), and
some DB functionality & some messaging functionality ( All that will get
installed using an installer etc. etc. ).
2. We have several "applications" running on top of that, exploiting the
base services for the UI (Downloaded or installed from a CD).
3. We have "functionality libraries", implemented as Assemblies, doing ...
whatever. Those are the so-called "plugins", and the y operate on data
provided by the "application" that runs on top of the "base". In essence,
the plugins operate on data, and use the UI to show stuff exploiting the UI
services of the "base" ( Also downloaded or installed from a CD).
4. There is a single username/password for the complete package ("base",
"applications"), and users have/have not registered for use of various
"applications", and features ("plugins") per application.
5. Therefore, I might be able to use plugin A under application A, but not
under application B.

My "plugins" won't do anything that wouldn't run with the Internet
permission. They're just data-crunchers. I just need to restrict their usage
per application & user.

I hope I won't be re-inventing the wheel, that's why i took so much time
looking into the lists before I decide to write code, but ... at this point,
I think that that's the only way forward :] even if I do realise afterwards
that I'd duplicated framework functionality ... oh well ... at least I'll
have learned something, right ? :D

Thanx for all the help,

Angel
O:]
"UAError" <nu**@null.null> wrote in message
news:q2********************************@4ax.com...

"Angelos Karantzalis" <ak**********@agiltech.gr> wrote:

.. I'll just have to do it myself then :D

You're still in the danger of reinventing the wheel and
,worse, creating yet another application that requires
administrator privileges to run.

You're building an application, which supports services in the form of
dynamically downloaded plugins.

OK standard users are often denied the privilege to
"install" anything. A downloaded .NET assembly can be
downloaded and run in a "sandbox" but it still is configured
by CAS to the "Internet" Permission set and that doesn't
allow much.

You can however get the "client" too install code groups and
permission sets that match your code through membership
conditions to grant your assembly(ies) permissions beyond
the ones found in the "Internet" permission set. However
these must at least be present on the Enterprise level
Security policy (marked as LevelFinal) which can only be
done by an administrator. If its not marked as "LevelFinal",
the code groups/permission sets will also have to be present
on the User level Security Policy and Machine level Security
Policy.

But ultimately CAS cannot grant more rights than the user
already has under Windows.

You can expect that more than one users will
be using the same installation. Some of those plugins though, need the userhas special authorization (role) to run, others don't.

This is were you are not specific enough - (A) does your
application not want them to have access to an application
feature or (B) is there a platform resource that the user
does not have access too.

if (A) then you need to implement you own RBS most likely
with GenericIdentity and GenericPrincipal.

if (B) let Windows Security handle it; .NET will generate an
exception. If you want to be able to disable features in the
absence of access rights use WindowsPrincipal.IsInRole - the
Windows Group can be one you created on the machine or in
the domain for the purposes of your application - existing
users will then simply have to be assigned windows group
memberships pertinent to your application.

To complicate the
matter a bit further, you can execute the plugin under a "login domain" -
you have multiple login domains in the app, and each time you try to do
anything, you do it under a login domain, a "context" if you will ... ,

This is were you lose me - I think there's breakdown of
communication here. To me a username that is valid in
multiple network domains still are multiple distinct
"users". I don't know what concept you are trying to convey
with "login domains".

However under windows it is possible for a windows user to
run an application as a different user and have certain
parts of the application run as a differrent user through
the use of impersonation (provided the necessary credentials
are present).

But even that privilege can be denied. To impersonate you
have to have the
SeTcbPrivilege "Act as part of the operating system"
(TCB = Trusted Computing Base)

privilege. This has been changed in .NET Server 2003 which
has:
SeImpersonatePrivilege "Impersonate a client after
authentication"

to close that vulnerabilty.

and
the plugins are shared between domains. But you need different roles to usethem under each domain ...

[UAError]

"Angelos Karantzalis" <ak**********@agiltech.gr> wrote:

Yeah, I can understand that the wording is a bit messy & confusing.

In simple terms:

1. We have an application "base", where it provides some GIS-related UI
functionality ( It can do "stuff" on a Map, displayed in 2D or 3D ), and
some DB functionality & some messaging functionality ( All that will get
installed using an installer etc. etc. ).
2. We have several "applications" running on top of that, exploiting the
base services for the UI (Downloaded or installed from a CD).
3. We have "functionality libraries", implemented as Assemblies, doing ...
whatever. Those are the so-called "plugins", and the y operate on data
provided by the "application" that runs on top of the "base". In essence,
the plugins operate on data, and use the UI to show stuff exploiting the UI
services of the "base" ( Also downloaded or installed from a CD).
4. There is a single username/password for the complete package ("base",
"applications"), and users have/have not registered for use of various
"applications", and features ("plugins") per application.
5. Therefore, I might be able to use plugin A under application A, but not
under application B.

My "plugins" won't do anything that wouldn't run with the Internet
permission. They're just data-crunchers. I just need to restrict their usage
per application & user.
just as long as you don't have access any files directly
from that assembly - you are restricted to OpenFileDialog
and SaveFileDialog.

I hope I won't be re-inventing the wheel, that's why i took so much time
looking into the lists before I decide to write code, but ... at this point,
I think that that's the only way forward :] even if I do realise afterwards
that I'd duplicated framework functionality ... oh well ... at least I'll
have learned something, right ? :D

Thanx for all the help,

Angel
O:]

Given that description and from what I know (there are more
competent people out there), I would use RBS and assign each
"plugin" its own role (that way each "plugin" only has to
know its own role). Then simply re-authorize (not
re-authenticate) the user every time the application
boundary is crossed.

During entry of the package authenticate the user and create
and populate a GenericIdentity for the user. Put that
GenericIdentity object in an GenericPrincpal which was
created with no roles. Assign that GenericPrincipal to
Thread.CurrentPrincipal.

When the user enters an "application context" get the
GenericIdentity from the GenericPrincipal from
Thread.CurrentPrincipal - pass the GenericIdentity, and the
"application context" identifier to an authorization object
that you create. The authorization object would consult your
license repository for all the "plugins" (roles) in the
specified application context for that GenericIdentity.Name.
Use the Identity and those "roles" (representing allowed
"plugins") to create a new GenericPrincipal. Have the
authorization object return that GenericPrincipal and then
assign it to Thread.CurrentPrincipal.

The beauty of the approach is that you can use imperative
RBS (IsInRole i.e. allowed to use plugin) to disable
navigation paths and you can use declarative RBS to secure
your methods to throw an exception if a navigation path is
accidentally left enabled.