Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Web Services > Authorization problem

Reply
Thread Tools

Authorization problem

 
 
Nikolay Petrov
Guest
Posts: n/a
 
      10-26-2004
The following code doesn't produse the expected effect to only allow the
members of Administrators group to access the web method, it stops everyone.
=========
<WebMethod(), _
PrincipalPermission(SecurityAction.Demand, Role:="Administrators")> _
Public Function HelloWorld() As String
Return "Hello World"
End Function
=========

The web service folder is set to require only Windows Authentication, which
goes fine. I can get the user credentials whitout any problem.

What is wrong?
TIA


 
Reply With Quote
 
 
 
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      10-26-2004
Did you try MACHINE\Administrators or the proper domain suffix? Windows
roles always have a prefix in .NET.

Joe K.

"Nikolay Petrov" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> The following code doesn't produse the expected effect to only allow
> the members of Administrators group to access the web method, it stops
> everyone.
> =========
> <WebMethod(), _
> PrincipalPermission(SecurityAction.Demand, Role:="Administrators")> _
> Public Function HelloWorld() As String
> Return "Hello World"
> End Function
> =========
>
> The web service folder is set to require only Windows Authentication,
> which goes fine. I can get the user credentials whitout any problem.
>
> What is wrong?
> TIA
>



 
Reply With Quote
 
 
 
 
Nikolay Petrov
Guest
Posts: n/a
 
      10-26-2004
I have tried this. Doesn't help.


"Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
in message news:%(E-Mail Removed)...
> Did you try MACHINE\Administrators or the proper domain suffix? Windows
> roles always have a prefix in .NET.
>
> Joe K.



 
Reply With Quote
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      10-26-2004
Are you certain that the client is being authenticated with Windows
authentication? It would probably be a good idea to dump out the value of
Context.User.Identity.Name and make sure it is the user that you think it
is.

Joe K.

"Nikolay Petrov" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
>I have tried this. Doesn't help.
>
>
> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
> in message news:%(E-Mail Removed)...
>> Did you try MACHINE\Administrators or the proper domain suffix? Windows
>> roles always have a prefix in .NET.
>>
>> Joe K.

>
>



 
Reply With Quote
 
Nikolay Petrov
Guest
Posts: n/a
 
      10-26-2004
I have done that. It is fine.
Something else is broken. The auditing don't show nothing also.

"Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
in message news:(E-Mail Removed)...
> Are you certain that the client is being authenticated with Windows
> authentication? It would probably be a good idea to dump out the value of
> Context.User.Identity.Name and make sure it is the user that you think it
> is.
>
> Joe K.
>
> "Nikolay Petrov" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>>I have tried this. Doesn't help.
>>
>>
>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>> wrote in message news:%(E-Mail Removed)...
>>> Did you try MACHINE\Administrators or the proper domain suffix? Windows
>>> roles always have a prefix in .NET.
>>>
>>> Joe K.

>>
>>

>
>



 
Reply With Quote
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      10-26-2004
One other thing to check:

Can you do a programmatic check instead of a declarative one? Try
Context.User.IsInRole("machine\administrators") or
Thread.CurrentPrincipal.IsInRole("machine\administ rators")?

Those should do the same thing as the declarative demand, but it is worth a
shot.

Another thing to try is to use reflection on _GetRoles private method on
WindowsIdentity to see what the actual values are. This can be helpful for
troubleshooting Windows group resolution. Don't use this in production
though!

Google will dig up a bunch of code samples showing how to do that if you
need it.

Joe K.

"Nikolay Petrov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I have done that. It is fine.
> Something else is broken. The auditing don't show nothing also.
>
> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
> in message news:(E-Mail Removed)...
>> Are you certain that the client is being authenticated with Windows
>> authentication? It would probably be a good idea to dump out the value
>> of Context.User.Identity.Name and make sure it is the user that you think
>> it is.
>>
>> Joe K.



 
Reply With Quote
 
Nikolay Petrov
Guest
Posts: n/a
 
      10-26-2004
Never heard of reflection
how to do?


"Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
in message news:(E-Mail Removed)...
> One other thing to check:
>
> Can you do a programmatic check instead of a declarative one? Try
> Context.User.IsInRole("machine\administrators") or
> Thread.CurrentPrincipal.IsInRole("machine\administ rators")?
>
> Those should do the same thing as the declarative demand, but it is worth
> a shot.
>
> Another thing to try is to use reflection on _GetRoles private method on
> WindowsIdentity to see what the actual values are. This can be helpful
> for troubleshooting Windows group resolution. Don't use this in
> production though!
>
> Google will dig up a bunch of code samples showing how to do that if you
> need it.
>
> Joe K.
>
> "Nikolay Petrov" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>I have done that. It is fine.
>> Something else is broken. The auditing don't show nothing also.
>>
>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>> wrote in message news:(E-Mail Removed)...
>>> Are you certain that the client is being authenticated with Windows
>>> authentication? It would probably be a good idea to dump out the value
>>> of Context.User.Identity.Name and make sure it is the user that you
>>> think it is.
>>>
>>> Joe K.

>
>



 
Reply With Quote
 
Joe Kaplan \(MVP - ADSI\)
Guest
Posts: n/a
 
      10-26-2004
'imports System.Security.Principal
'imports System.Reflection

Function GetRoles(byval identity as WindowsIdentity) as String()

Dim idType As Type
idType = GetType(WindowsIdentity)
Dim result As Object =
idType.InvokeMember("_GetRoles",BindingFlags.Stati c Or
BindingFlags.InvokeMethod Or BindingFlags.NonPublic,Nothing, identity, New
Object() {identity.Token}, Nothing)
Dim roles() As String = DirectCast(result, String())
Return roles

End Function

Like I said, this is for troubleshooting only, not for production code.
This may not work in future versions of the framework, but does on 1.1.

Joe K.

"Nikolay Petrov" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Never heard of reflection
> how to do?
>
>
> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
> in message news:(E-Mail Removed)...
>> One other thing to check:
>>
>> Can you do a programmatic check instead of a declarative one? Try
>> Context.User.IsInRole("machine\administrators") or
>> Thread.CurrentPrincipal.IsInRole("machine\administ rators")?
>>
>> Those should do the same thing as the declarative demand, but it is worth
>> a shot.
>>
>> Another thing to try is to use reflection on _GetRoles private method on
>> WindowsIdentity to see what the actual values are. This can be helpful
>> for troubleshooting Windows group resolution. Don't use this in
>> production though!
>>
>> Google will dig up a bunch of code samples showing how to do that if you
>> need it.
>>
>> Joe K.
>>
>> "Nikolay Petrov" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>>I have done that. It is fine.
>>> Something else is broken. The auditing don't show nothing also.
>>>
>>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>>> wrote in message news:(E-Mail Removed)...
>>>> Are you certain that the client is being authenticated with Windows
>>>> authentication? It would probably be a good idea to dump out the value
>>>> of Context.User.Identity.Name and make sure it is the user that you
>>>> think it is.
>>>>
>>>> Joe K.

>>
>>

>
>



 
Reply With Quote
 
Nikolay Petrov
Guest
Posts: n/a
 
      10-26-2004
Ok, I'll try it tommorow and let you know.
Thanks for help.


"Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
in message news:%(E-Mail Removed)...
> 'imports System.Security.Principal
> 'imports System.Reflection
>
> Function GetRoles(byval identity as WindowsIdentity) as String()
>
> Dim idType As Type
> idType = GetType(WindowsIdentity)
> Dim result As Object =
> idType.InvokeMember("_GetRoles",BindingFlags.Stati c Or
> BindingFlags.InvokeMethod Or BindingFlags.NonPublic,Nothing, identity, New
> Object() {identity.Token}, Nothing)
> Dim roles() As String = DirectCast(result, String())
> Return roles
>
> End Function
>
> Like I said, this is for troubleshooting only, not for production code.
> This may not work in future versions of the framework, but does on 1.1.
>
> Joe K.
>
> "Nikolay Petrov" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Never heard of reflection
>> how to do?
>>
>>
>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>> wrote in message news:(E-Mail Removed)...
>>> One other thing to check:
>>>
>>> Can you do a programmatic check instead of a declarative one? Try
>>> Context.User.IsInRole("machine\administrators") or
>>> Thread.CurrentPrincipal.IsInRole("machine\administ rators")?
>>>
>>> Those should do the same thing as the declarative demand, but it is
>>> worth a shot.
>>>
>>> Another thing to try is to use reflection on _GetRoles private method on
>>> WindowsIdentity to see what the actual values are. This can be helpful
>>> for troubleshooting Windows group resolution. Don't use this in
>>> production though!
>>>
>>> Google will dig up a bunch of code samples showing how to do that if you
>>> need it.
>>>
>>> Joe K.
>>>
>>> "Nikolay Petrov" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>>I have done that. It is fine.
>>>> Something else is broken. The auditing don't show nothing also.
>>>>
>>>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
>>>> wrote in message news:(E-Mail Removed)...
>>>>> Are you certain that the client is being authenticated with Windows
>>>>> authentication? It would probably be a good idea to dump out the
>>>>> value of Context.User.Identity.Name and make sure it is the user that
>>>>> you think it is.
>>>>>
>>>>> Joe K.
>>>
>>>

>>
>>

>
>



 
Reply With Quote
 
Patrick.O.Ige
Guest
Posts: n/a
 
      10-27-2004
Hi,
I'm using form authentication with Active Directory not a Database.
Can you give me a hint how i can GetRoles from the Active Directory and
later perform Authorisation?
Thx

"Joe Kaplan (MVP - ADSI)" wrote:

> 'imports System.Security.Principal
> 'imports System.Reflection
>
> Function GetRoles(byval identity as WindowsIdentity) as String()
>
> Dim idType As Type
> idType = GetType(WindowsIdentity)
> Dim result As Object =
> idType.InvokeMember("_GetRoles",BindingFlags.Stati c Or
> BindingFlags.InvokeMethod Or BindingFlags.NonPublic,Nothing, identity, New
> Object() {identity.Token}, Nothing)
> Dim roles() As String = DirectCast(result, String())
> Return roles
>
> End Function
>
> Like I said, this is for troubleshooting only, not for production code.
> This may not work in future versions of the framework, but does on 1.1.
>
> Joe K.
>
> "Nikolay Petrov" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Never heard of reflection
> > how to do?
> >
> >
> > "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)> wrote
> > in message news:(E-Mail Removed)...
> >> One other thing to check:
> >>
> >> Can you do a programmatic check instead of a declarative one? Try
> >> Context.User.IsInRole("machine\administrators") or
> >> Thread.CurrentPrincipal.IsInRole("machine\administ rators")?
> >>
> >> Those should do the same thing as the declarative demand, but it is worth
> >> a shot.
> >>
> >> Another thing to try is to use reflection on _GetRoles private method on
> >> WindowsIdentity to see what the actual values are. This can be helpful
> >> for troubleshooting Windows group resolution. Don't use this in
> >> production though!
> >>
> >> Google will dig up a bunch of code samples showing how to do that if you
> >> need it.
> >>
> >> Joe K.
> >>
> >> "Nikolay Petrov" <(E-Mail Removed)> wrote in message
> >> news:(E-Mail Removed)...
> >>>I have done that. It is fine.
> >>> Something else is broken. The auditing don't show nothing also.
> >>>
> >>> "Joe Kaplan (MVP - ADSI)" <(E-Mail Removed)>
> >>> wrote in message news:(E-Mail Removed)...
> >>>> Are you certain that the client is being authenticated with Windows
> >>>> authentication? It would probably be a good idea to dump out the value
> >>>> of Context.User.Identity.Name and make sure it is the user that you
> >>>> think it is.
> >>>>
> >>>> Joe K.
> >>
> >>

> >
> >

>
>
>

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
URL Authorization does not override File Authorization? SeanRW ASP .Net Security 1 05-25-2006 06:18 AM
Form authorization problem nick ASP .Net 3 07-08-2004 07:38 AM
Problem in Web Service Authorization Mode Shalini ASP .Net 1 03-04-2004 02:30 PM
Authorization problem in my webapp Abhishek Srivastava ASP .Net 1 01-20-2004 01:02 PM
Bug in Authorization??? IIS 5 Config Problem?? Mark Olbert ASP .Net 4 01-13-2004 02:31 AM



Advertisments