Security Model

  • Thread starter Thread starter Z D
  • Start date Start date
Z

Z D

Good Morning,

I was looking for some feedback, guidance, input, comments, suggestions or
just general thoughts on the following:

For our internal development, I'm trying to create a general, reusable
security framework that is very flexible. It would have to handle both
Authentication and Authorization. The access levels allowed on each 'object'
would be: View/Edit/Read/Write.

Essentially, the first thought that came to mind was to model it after the
way ACL's work in Windows NTFS. This way, I have the flexibility to assign
View/Edit/Read/Write permissions to each button, form, or any other
object/grouping of objects available in any given application.

Unfortunately, all I know about the way ACL's work is what I see as an end
user. I'm assuming each 'object' gets some form of a unique identifier
(guid?). Each user in the system is then linked to a guid along with an
access level (Read, write, etc). This info is stored in a database/xml
file/wherever. Is this a valid approach?

***The question then becomes: How do I do this in an efficient & elegant
manner? I dont want to have to put an IF statement around each and every
button, form or object access!

How do you guys do it? Are there any resources, other people that have
done/attempted something like this in the past?

thanks in advance!
-ZD
 
Z D,

Generally, I'm not too concerned about user interface element access.
If you have designed your app correctly, you can have people hitting
whatever button they want, because those buttons will call into your
business layer, which has code that is not tied to the UI. Is is there that
you will begin your security checks.

Now, in this area, you have a number of options. It's actually possible
to create your own ACL (and take advantage of the infrastructure that
windows provides). There is a good article showing how to do this (in
unmanaged code which can be converted to managed code) on MSDN titled
"Techniques for Securing Private Objects in Your Applications", located at
(watch for line wrap):

http://msdn.microsoft.com/security/...ary/en-us/dnsecure/html/SecPrivateObjects.asp

Hope this helps.
 
Arghh!, this sounds like a hellish project to me. If you really need this
sort of control you need to come up with a set of interfaces for each of
your objects to implement.

For example, your might want a button to be greyed out if no access is
applied or in the case of a text box, you might want the contents to show
blank and the box to remain visible.

This can get awfully complex because its not really something which .NET
implements at this level of granularity. You will have to come up with
inherited designs for all your design time objects.

If I were you, I would think of another approach to this.


Regards - OHM
 
a few existing options you have.

1. check out role based security in .NET.
2. check out Authorization Manager, or AzMan, which is COM based, you can use through Interop.
3. check out Microsoft Application Security and Profile Block.
4. after reading those, you still feel they are not good enough, then you can roll your own by using them as a template

sorry I don't keep links around, but a quick search on MSDN will guide you in the right direction.

----- Z D wrote: -----

Good Morning,

I was looking for some feedback, guidance, input, comments, suggestions or
just general thoughts on the following:

For our internal development, I'm trying to create a general, reusable
security framework that is very flexible. It would have to handle both
Authentication and Authorization. The access levels allowed on each 'object'
would be: View/Edit/Read/Write.

Essentially, the first thought that came to mind was to model it after the
way ACL's work in Windows NTFS. This way, I have the flexibility to assign
View/Edit/Read/Write permissions to each button, form, or any other
object/grouping of objects available in any given application.

Unfortunately, all I know about the way ACL's work is what I see as an end
user. I'm assuming each 'object' gets some form of a unique identifier
(guid?). Each user in the system is then linked to a guid along with an
access level (Read, write, etc). This info is stored in a database/xml
file/wherever. Is this a valid approach?

***The question then becomes: How do I do this in an efficient & elegant
manner? I dont want to have to put an IF statement around each and every
button, form or object access!

How do you guys do it? Are there any resources, other people that have
done/attempted something like this in the past?

thanks in advance!
-ZD
 
Hi Nicholas,

Thanks very much for your response.

1) I agree with you. My UI is totally separated from my core business
logic. However, I would still like the UI to be able to "query" the
business logic so that if a user does not have access to hit the delete
button then it would be greyed out. This just provides for a richer user
experience IMO.

2) Thankyou very much for the link. I will definetly take a look at it.

Thanks again,
-ZD


Nicholas Paldino said:
Z D,

Generally, I'm not too concerned about user interface element access.
If you have designed your app correctly, you can have people hitting
whatever button they want, because those buttons will call into your
business layer, which has code that is not tied to the UI. Is is there that
you will begin your security checks.

Now, in this area, you have a number of options. It's actually possible
to create your own ACL (and take advantage of the infrastructure that
windows provides). There is a good article showing how to do this (in
unmanaged code which can be converted to managed code) on MSDN titled
"Techniques for Securing Private Objects in Your Applications", located at
(watch for line wrap):

http://msdn.microsoft.com/security/...ary/en-us/dnsecure/html/SecPrivateObjects.asp

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)



Z D said:
Good Morning,

I was looking for some feedback, guidance, input, comments, suggestions or
just general thoughts on the following:

For our internal development, I'm trying to create a general, reusable
security framework that is very flexible. It would have to handle both
Authentication and Authorization. The access levels allowed on each 'object'
would be: View/Edit/Read/Write.

Essentially, the first thought that came to mind was to model it after the
way ACL's work in Windows NTFS. This way, I have the flexibility to assign
View/Edit/Read/Write permissions to each button, form, or any other
object/grouping of objects available in any given application.

Unfortunately, all I know about the way ACL's work is what I see as an end
user. I'm assuming each 'object' gets some form of a unique identifier
(guid?). Each user in the system is then linked to a guid along with an
access level (Read, write, etc). This info is stored in a database/xml
file/wherever. Is this a valid approach?

***The question then becomes: How do I do this in an efficient & elegant
manner? I dont want to have to put an IF statement around each and every
button, form or object access!

How do you guys do it? Are there any resources, other people that have
done/attempted something like this in the past?

thanks in advance!
-ZD
 
Hi OHM,

Thanks for your response.

I agree that it seems like its going to be a tough job. Do you have any
suggestions for alternatives right off the top of your head? How do you go
about controlling access in your applications?

thanks!
-ZD
 
Hi Daniel,

Thanks for responding.

I actually came across the App Security & Profile block just a few minutes
ago searching on MSDN. It seems very interesting and I may be able to
modify/learn from it. I did notice however that it's based only on Roles
instead of ACL type access. Not sure if that will be a big deal, I will look
into it.

Thanks again!
-ZD

Daniel Jin said:
a few existing options you have.

1. check out role based security in .NET.
2. check out Authorization Manager, or AzMan, which is COM based, you can use through Interop.
3. check out Microsoft Application Security and Profile Block.
4. after reading those, you still feel they are not good enough, then
you can roll your own by using them as a template
 
Hi AlexS,

Sorry, Delete is definetly a requirement. I just forgot to list it in my
post. Not sure about Confirm or Authorize, how would those fit in?

My plan was to create the foundation using ACL's, etc in order to provide a
very flexible security framework. The business logic would then encapsulate
& use this at a higher level when any authorization is required. This would
take into account all the business & "fuzzy" requirements.

Thank's very much for your response. I like the idea of using attributes, I
will look into it further.

Regards,
-ZD
 
ZD,
I created a home grown security model for my projects. The model is
directly linked to our HR application and works well as any changes in staff
are immediately placed into action.

I created a simple database model that houses:

(1) views into the users and groups tables in HR
(2) Applications
(3) Connection strings
(4) User and Group Roles
(5) An other users tables for users that are not employees (consultants that
may need access to the application that have rights to log into the network)

On top of these tables I created a simple object model that is used to query
the database. The model is used in any of my UI's, both windows and web.
Security is role based and is enforced in the UI, trying to implement the
security in your business layer is not only difficult but probably
unnecessary.

Regards,
Dan
 
Hi, Z D

Why you do not include Delete into your model? IMO, write is more like
Update. Do you consider Add role too? What about Confirm or Authorize?

You make one big "mistake" in planning your framework - you start from
technical issues, like ACLs, NTFS and available low-level functionality.
Business requirements usually ignore technical issues and are more general
and fuzzy than simple file/objects permissions.

Flexible security framework should target flexible way of permission
definition and efficient implementation of declaration and run-time checks.
I would suggest as first step to take a look at Attributes namespaces in
..Net and also Permission classes and methods. It's not really useful,
however good starting point

HTH
Alex
 
Back
Top