Authorization problem

Discussion in 'ASP .Net Web Services' started by Nikolay Petrov, Oct 26, 2004.

  1. 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
     
    Nikolay Petrov, Oct 26, 2004
    #1
    1. Advertising

  2. Did you try MACHINE\Administrators or the proper domain suffix? Windows
    roles always have a prefix in .NET.

    Joe K.

    "Nikolay Petrov" <> wrote in message
    news:%...
    > 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
    >
     
    Joe Kaplan \(MVP - ADSI\), Oct 26, 2004
    #2
    1. Advertising

  3. I have tried this. Doesn't help.


    "Joe Kaplan (MVP - ADSI)" <> wrote
    in message news:%...
    > Did you try MACHINE\Administrators or the proper domain suffix? Windows
    > roles always have a prefix in .NET.
    >
    > Joe K.
     
    Nikolay Petrov, Oct 26, 2004
    #3
  4. 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" <> wrote in message
    news:%...
    >I have tried this. Doesn't help.
    >
    >
    > "Joe Kaplan (MVP - ADSI)" <> wrote
    > in message news:%...
    >> Did you try MACHINE\Administrators or the proper domain suffix? Windows
    >> roles always have a prefix in .NET.
    >>
    >> Joe K.

    >
    >
     
    Joe Kaplan \(MVP - ADSI\), Oct 26, 2004
    #4
  5. I have done that. It is fine.
    Something else is broken. The auditing don't show nothing also.

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

    >>
    >>

    >
    >
     
    Nikolay Petrov, Oct 26, 2004
    #5
  6. 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\administrators")?

    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" <> wrote in message
    news:...
    >I have done that. It is fine.
    > Something else is broken. The auditing don't show nothing also.
    >
    > "Joe Kaplan (MVP - ADSI)" <> wrote
    > in message news:...
    >> 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.
     
    Joe Kaplan \(MVP - ADSI\), Oct 26, 2004
    #6
  7. Never heard of reflection ;-)
    how to do?


    "Joe Kaplan (MVP - ADSI)" <> wrote
    in message news:...
    > 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\administrators")?
    >
    > 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" <> wrote in message
    > news:...
    >>I have done that. It is fine.
    >> Something else is broken. The auditing don't show nothing also.
    >>
    >> "Joe Kaplan (MVP - ADSI)" <>
    >> wrote in message news:...
    >>> 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, Oct 26, 2004
    #7
  8. '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.Static 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" <> wrote in message
    news:...
    > Never heard of reflection ;-)
    > how to do?
    >
    >
    > "Joe Kaplan (MVP - ADSI)" <> wrote
    > in message news:...
    >> 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\administrators")?
    >>
    >> 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" <> wrote in message
    >> news:...
    >>>I have done that. It is fine.
    >>> Something else is broken. The auditing don't show nothing also.
    >>>
    >>> "Joe Kaplan (MVP - ADSI)" <>
    >>> wrote in message news:...
    >>>> 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.

    >>
    >>

    >
    >
     
    Joe Kaplan \(MVP - ADSI\), Oct 26, 2004
    #8
  9. Ok, I'll try it tommorow and let you know.
    Thanks for help.


    "Joe Kaplan (MVP - ADSI)" <> wrote
    in message news:%...
    > '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.Static 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" <> wrote in message
    > news:...
    >> Never heard of reflection ;-)
    >> how to do?
    >>
    >>
    >> "Joe Kaplan (MVP - ADSI)" <>
    >> wrote in message news:...
    >>> 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\administrators")?
    >>>
    >>> 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" <> wrote in message
    >>> news:...
    >>>>I have done that. It is fine.
    >>>> Something else is broken. The auditing don't show nothing also.
    >>>>
    >>>> "Joe Kaplan (MVP - ADSI)" <>
    >>>> wrote in message news:...
    >>>>> 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, Oct 26, 2004
    #9
  10. 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.Static 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" <> wrote in message
    > news:...
    > > Never heard of reflection ;-)
    > > how to do?
    > >
    > >
    > > "Joe Kaplan (MVP - ADSI)" <> wrote
    > > in message news:...
    > >> 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\administrators")?
    > >>
    > >> 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" <> wrote in message
    > >> news:...
    > >>>I have done that. It is fine.
    > >>> Something else is broken. The auditing don't show nothing also.
    > >>>
    > >>> "Joe Kaplan (MVP - ADSI)" <>
    > >>> wrote in message news:...
    > >>>> 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.
    > >>
    > >>

    > >
    > >

    >
    >
    >
     
    Patrick.O.Ige, Oct 27, 2004
    #10
  11. I think the standard Forms Authentication with ASP.NET article is an okay
    starting point. I'd suggest you rip out their group lookup code and replace
    it with some code that uses tokenGroups instead of memberOf. There are many
    advantages to this approach.

    http://support.microsoft.com/default.aspx?scid=kb;en-us;326340
    http://groups.google.com/groups?hl=en&lr=&selm=

    If you are having trouble with ASP.NET and security contexts in S.DS, please
    read this too:
    http://support.microsoft.com/default.aspx?scid=kb;en-us;329986

    The alternatives to this are to use the LogonUser API or SSPI to
    authenticate the user and create a Windows token that can be turned into a
    WindowsPrincipal for role-based authorization. This approach is actually
    better in many ways to the LDAP approach, but might not work in all
    situations. These have also been discussed endlessly on the public
    newsgroups.

    Joe K.

    "Patrick.O.Ige" <> wrote in message
    news:D...
    > 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.Static 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" <> wrote in message
    >> news:...
    >> > Never heard of reflection ;-)
    >> > how to do?
    >> >
    >> >
    >> > "Joe Kaplan (MVP - ADSI)" <>
    >> > wrote
    >> > in message news:...
    >> >> 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\administrators")?
    >> >>
    >> >> 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" <> wrote in message
    >> >> news:...
    >> >>>I have done that. It is fine.
    >> >>> Something else is broken. The auditing don't show nothing also.
    >> >>>
    >> >>> "Joe Kaplan (MVP - ADSI)" <>
    >> >>> wrote in message news:...
    >> >>>> 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.
    >> >>
    >> >>
    >> >
    >> >

    >>
    >>
    >>
     
    Joe Kaplan \(MVP - ADSI\), Oct 27, 2004
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Olbert
    Replies:
    4
    Views:
    486
    Steven Cheng[MSFT]
    Jan 13, 2004
  2. Abhishek Srivastava

    Authorization problem in my webapp

    Abhishek Srivastava, Jan 20, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    320
    Mohamed El Ashamwy
    Jan 20, 2004
  3. Shalini
    Replies:
    1
    Views:
    364
    Shalini
    Mar 4, 2004
  4. nick

    Form authorization problem

    nick, Jul 8, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    1,450
  5. SeanRW
    Replies:
    1
    Views:
    367
    Dominick Baier [DevelopMentor]
    May 25, 2006
Loading...

Share This Page