none
Securing Services and Operations RRS feed

  • Question

  • I am new to WCF.  I have set up a Service UserService.  At the moment I use a <userNameAuthentication>  which is a UserNamePasswordValidator to secure the service.  Once a user logs in, I also assign a token to be passed in the header to make sure that user is only trying to access data that they are allowed too.   Recently, there are some functions in the UserService, that do not require the user to be authenticated. 

    Is there a way to have parts of the service require authentication and other operations that do not?  What is the proper way to allow this type of control over a service in WCF?

    Thank you

    Wednesday, January 27, 2016 6:47 PM

All replies

  • Maybe you need to services.
    Thursday, January 28, 2016 1:49 AM
  • Hi alz0id,

    According to your description, in my understanding is that you want to set the authorization

    for different roles.

    As far as I know, we can set the PrincipalPermission in our service.

    For more information, please refer to the following links:

    1.WCF - Authentication and Authorization in Enterprise Architecting

    2.Custom Authorization in WCF

    If I miss understood your question, please let me know.

    =========================================================

    This response contains two reference to a third party World Wide Web site. Microsoft is

    providing this information as a convenience to you. Microsoft does not control these

    sites and has not tested any software or information found on these sites; therefore,

    Microsoft cannot make any representations regarding the quality, safety, or suitability

    of any software or information found there. There are inherent dangers in the use of any

    software found on the Internet, and Microsoft cautions you to make sure that you

    completely understand the risk before retrieving any software from the Internet.

    Hope it helps.

    Best Regards,

    Wanjun Dong


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place. Click HERE to participate the survey.

    Thursday, January 28, 2016 7:44 AM
    Moderator
  • Thanks Wanjun.  Roles work for some of my use cases, however there is still one thing missing.  I am issuing a token to verify that the user accessing an operation is allowed to access the data they are asking for.

    I have 2 operations:

    <PrincipalPermission(SecurityAction.Demand, Role:="RUser")>
    Public Function GetAccount() ...
    
    <PrincipalPermission(SecurityAction.Demand, Role:="APIUser")>
    Public Function Search(..) ....

    I have an IDispatchMessageInspector that checks for the token header.  The logic for checking the token is different for GetAccount and Search.  How I can apply a different message inspector to different operations?  I would prefer to beable to add a custom attribute to inspect the message at the Operation level.  However, I only see Parameter inspectors at that level.


    • Edited by alz0id Tuesday, February 2, 2016 1:57 PM bad wording
    Tuesday, February 2, 2016 1:57 PM
  • Hello,

    >>How I can apply a different message inspector to different operations?
    IDispatchMessageInspector is used in Service level which means it will apply for the all the operations, so it is not possible to appy different message inspectors to different operations.

    For more information, please try to refer to the following article:
    #Message Inspectors:
    http://blogs.msdn.com/b/endpoint/archive/2011/04/23/wcf-extensibility-message-inspectors.aspx .

    >>Is there a way to have parts of the service require authentication and other operations that do not? 

    In my mind using the IDispatchMessageInspector.AfterReceiveRequest method is not a good idea to achieve the above goal, because you are required to manually parse the message, i.e. decode the info,  parse the SOAP, etc. 
    The most simple solution to achieve the above goal is to use 2 services, one service is used for authenticated users and the other service is for anonymous calls.


    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.





    Tuesday, February 9, 2016 3:47 PM
    Moderator
  • After reading Wanjun's answer, I required all users to login. I used a custom AuthorizationPolicy and Principal to require certain roles for each operation.  That solved that problem.

    I still need operation level checking because I provide the users with a token.  The users can call an Operation asking for their Account info.  I use the token to make sure that the user who is asking for account "A" is allowed to access account "A".  This will prevent people who are calling my service to get authenticated and then change the  account id in the message.

    For every operation that asks for account info I need to inspect the token.  The token is stored in a HTTP header.

    Is there a way, at the operation level to inspect the HTTP headers or is there a way to implement this?



    • Edited by alz0id Wednesday, February 10, 2016 6:40 PM
    Wednesday, February 10, 2016 6:12 PM
  • Hi alz0id,

    >>Is there a way, at the operation level to inspect the HTTP headers or is there a way to implement this?

    In my mind in order to implement the above requirement, you may use the IDispatchMessageInspector to inspect the HTTP headers. For more information, please try to refer to the this article:Message Inspectors.

    Best Regards,
    Amy Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, February 29, 2016 2:21 AM
    Moderator