Re: Role based security flaw?
- From: "William Stacey [MVP]" <william.stacey@xxxxxxxxx>
- Date: Mon, 20 Mar 2006 16:13:00 -0500
| #2 and #3 are easy; use PrincipalPermission. #1 requires you to add
| lines of code to places... My question was trying to gauge if the
| benefit would be worth the time.
You could use one line of code in your entry point method(s), to verify user
or throw exception, then use only attributes in your method chain after
that.
I would make sure your public remote entry points are few and well protected
with your Verify() helper. Then after you do Impersonate, your role
security attributes should be fine.
| Even if all those are met, its possible that the identity was
| authenticated from a rogue domain (well, it might be, I'm not 100% if
| that's possible).
If that is possible, then what is more secure? So where does that leave
this? Is this a client app or a client/server. How are you authorizing
clients to the server (wse, negotiatestream/remoting, etc)?
--wjs
.
- References:
- Role based security flaw?
- From: Andy
- Re: Role based security flaw?
- From: Joe Kaplan \(MVP - ADSI\)
- Re: Role based security flaw?
- From: oldbear
- Re: Role based security flaw?
- From: Andy
- Re: Role based security flaw?
- From: William Stacey [MVP]
- Re: Role based security flaw?
- From: Andy
- Role based security flaw?
- Prev by Date: Least Privilege User Accounts
- Next by Date: Re: Online Only Digital Signature
- Previous by thread: Re: Role based security flaw?
- Next by thread: Re: Role based security flaw?
- Index(es):
Relevant Pages
|