Reg Role BAsed security..

M

Madan Nayak

Hi All..

Can any body detail out the basic diff/advatages/disadvantage over acheiving
the role based security and the same thing in case of acheived through
session.....


Thnaks
Madan
 
M

Madan Nayak

Hi Amit..

I think you did not get the issue..
I had asked the the advntages of using Role baes security over doing the
same thing in session...

I know the Rolebased secuirity is a programatic approach.......Session has
its own disadvantages....

Apart frrom that how do I convince a developerr that Role based securrrity
is good ans safe....

Pl. advise.
Madan
 
M

Madan Nayak

Hi

Does Any one fom microsoft tell me the design goal of rolebased security in
..Net framewor???
 
M

Madan Nayak

Hi Amit..

I just want to know why should I go for the role base securrity, which I can
achieve by using sessions?

I think I am now much clear.

Thanks In Advance.
Madan
 
J

Joe Kaplan \(MVP - ADSI\)

Role-based security in .NET allows you to allow or deny access to
functionality within your code based on a user's identity and role
membership. ASP.NET session state is just a storage container for data
associated with a given web session.

Role-based security in .NET is deeply embedded in the API. This is evident
through the System.Security.Principal namespace, PrincipalPermission and
PrincipalPermissionAttribute classes, and Thread.CurrentPrincipal member.
There is also strong integration support for it in ASP.NET, both with
Windows authentication and Forms authentication with the FormsPrincipal
class.

So, essentially I would tell you to use role-based security when it is
appropriate. This will give you the most consistent method of using
role-based security and allow you to take advantage of all of the built-in
platform service support for it. If your web application requires it, it is
certainly okay to store your principal information in Session state in order
to save extra lookups to the store, so you may use the two together. You
may also use the cache for this.

I hope that helps some. If you have more detailed questions, please ask.

Joe K.
 
N

.NET Follower

just as there is a method of USer.IsInRole
to check whom to give access..
we can even write our method
like the above
so we will retrieve from session the groups and check in the function
whether the user belongs to the group

so there is no need of the Pricipal classes and stuff????/

please clarify??
 
J

Joe Kaplan \(MVP - ADSI\)

I'm not saying you have to use the IPrincipal class, I'm just suggesting
that you should use it where appropriate.

With IPrincipal, you get a lot more support from the Framework. For
example, if you use Windows authentication in IIS, the IPrincipal in the
current HttpContext will already contain a WindowsPrincipal that has all of
the user's domain groups in it. You don't have to do anything. IPrincipal
lets you use the PrincipalPermission class as well as the
PrincipalPermissionAttribute class, so that you you can just add attributes
to you code to allow access.

IPrincipal integrates with the UrlAuthorizationModule, so you can allow and
deny access to various resources in your ASP.NET application via the
<allow/> and <deny/> tags in web.config.

Finally, IPrincipal is associated with the currently executing thread, so
you can get the IPrincipal associated with the request from components that
have no reference to your ASP.NET code or session variables by simply
calling Thread.CurrentThread.CurrentPrincipal (or using the
PrincipalPermission or PrincipalPermissionAttribute classes). Thus if your
code is factored into several tiers (as is the generally recommended .NET
application architecture), you still have all of these role-based security
services available to you.

You don't get any of that extra support by simply having a function and
using session variables.

It is still possible to store your role-information in session state if you
like. In that case, the general practice is to handle the
Application_AuthenticateRequest event in global.asax and create the
IPrincipal object based on your stored groups in that function. Thus it is
very easy to integrate into the .NET role-based security framework. You can
also do this in an HttpModule very easily. This isn't really significantly
more work than writing a function to check group membership.

So, I'm not saying that you have to use IPrincipal. I'm simply suggesting
that there are some compelling benefits you get from using the APIs the way
they were intended and it isn't very difficult to integrate with the system.

HTH,

Joe K.
 
M

Madan Nayak

Hi Joe.

I have used Role based security with Custom Principal.

My question is the same security I can achive by using session.

So what are the advantages of using rolebased security..over using session..

I know few advantages.. Like it is a better programatic approach... Only I
have to check IS InRole()....

What else...
 
J

Joe Kaplan \(MVP - ADSI\)

I thought I just explained all of the additional advantages you get with
using IPrincipal in my previous post (which is quoted below). Those were
all the advantages I could think of. Do you need more?

Joe K.
 
M

Madan Nayak

Thanks Joe.


Joe Kaplan (MVP - ADSI) said:
I thought I just explained all of the additional advantages you get with
using IPrincipal in my previous post (which is quoted below). Those were
all the advantages I could think of. Do you need more?

Joe K.

it state
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top