Sunday, November 25, 2012

Authentication and Authorization in WCF Services

Authentication and Authorization in WCF Services
After we create any wcf service, some questions related to security of our service pops ups in our mind more often what we require to know in this regard is
a)       How to control access to our service by only predefined clients?
b)       What functionality of service is exposed to what client?
WCF authentication and authorization is the answer to this question. Authentication enables us to identify clients that call the service. Authorization enables us to determine what operations authenticated clients can access.
To authorize, we first need to authenticate. To do that, you must be able to identify clients. Clients can identify themselves by providing evidence such as a Windows account, a user name / password or a certificate. Clients must also know that they are calling the service they intend to call. Services can identify themselves by providing a certificate.
A WCF service is a .NET application hence one can use familiar security techniques, including code access and role-based security. At the same time the client and service communicate by exchanging XML messages. You may need to secure these messages as well.
Protecting messages as they are transferred from client to server and back is known as transfer security.
WCF provides two mechanisms for transfer security:
1)       Transport security :
The packets sent “on the wire” include the caller’s credentials and the message. Both of which are encrypted using whatever mechanism the transport protocol uses. For example, if you use TCP, you will likely use Transport Layer Security (TLS) and if you use HTTPS, you will likely use Secure Sockets Layer (SSL).
   It is generally faster to encrypt and decrypt messages that use transport security and you can benefit from hardware acceleration to improve performance.
    A downside to transport security is that messages are encrypted only from point to point. Suppose a client sends a message to a service. The client encrypts the message and the service decrypts it. If the service then forwards the message to another service, the service forwarding the message will not automatically encrypt it.
     Transport security is interoperable because Transport security does require both clients and services to support the WS-Security specification unlike message security.
By default, the following bindings use transport security
a)        NetTcpBinding
b)        NetNamedPipesBinding
c)         NetMsmqBinding
d)        NePeerBinding
e)        MsmqIntegrationBinding

2)       Message security:
The caller’s credentials are included in the message and the message is encrypted using the WS-Security specification. In case of message security the service will encrypt the message before passing it on to another service unlike transport security.
   A downside to message security is that it requires both clients and services to support the WS-Security specification
By default, the following bindings use message security
a)       WSHttpBinding
b)       WS2007HttpBinding
c)        WSDualHttpBinding
d)       WSFederationBinding
e)       WS2007FederationBinding

3)       No security: The BasicHttpBinding by default uses none as its security mode. In other words, message sent using this binding are not secure. This enables interoperability with ASMX Web services.
     By modifying either properties of the binding or by specifying service behaviors, we can associate different security mode with binding other than its default security mode.
WCF supports the following six security modes:
1)       None-Messages are not secured.
2)       Transport-Messages are secured using transport security. You can use this in the scenarios of internal self-hosted and Web-hosted services.
3)       Message: Messages are secured using message security. You can use this in the scenario of internal self-hosted service.
4)       TransportWithMessageCredential: Message protection and authorization occur at the transport level and credentials are passed with the message. You can use this in the scenario of public Web-hosted service.
5)       TransportCredentialOnly: Credentials are passed at the transport level but the message is not encrypted. This option is available only if you are using the BasicHttpBinding binding.
6)       Both: Messages are secured using both transport level and message level security. This is supported only if you are using Microsoft Message Queue Server.
WCF clients & services identify themselves by passing credentials.
Credential types applicable to transport level security:
1)       Windows: The client uses a Windows token representing the logged in user’s Windows identity. The service uses the credentials of the process identity or an SSL certificate. You can use this in scenario of internal self-hosted service.    
2)       Basic: The client passes a user name and password to the service. Typically, the user will enter the user name and password in a login dialog box. The service uses a SSL certificate. This option is available only with HTTP protocols. You can use this in the scenario of internal Web-hosted service.                                                   
3)       Certificate: The client uses an X.509 certificate and the service uses either that certificate or an SSL certificate.
4)       NTLM: The service validates the client using a challenge/response scheme against Windows accounts. The service uses a SSL certificate. This option is available only with HTTP protocols.                                                                   
5)       None: Here the service does not validate the client.
Credential types applicable to message level security:
1)       Windows: Same as above                                                                                                                                                     
2)       UserName: The client passes a user name and password to the service. Typically, the user will enter the user name and password in a login dialog box.The service can validate the user name and password using a Windows account or the ASP.NET membership provider. You can use this in the scenario of public Web-hosted service.                                  
3)       Certificate: Same as above                                                                                                                                                    
4)       IssueToken. The client and service use the Secure Token Service, which issues tokens the client and service trust. Windows CardSpace uses the Secure Token Service.                                                            
5)       None : Here the service does not validate the client.
6)       Authorizing Client:
    Authorization enables you to determine what operations authenticated clients can access.
WCF supports three basic approaches to authorization:
1)       Role-based: Role Based Access to a service and to operations of the service is based on the user’s role.                            
2)       Identity base: Identity Based Access is based on claims made within the user’s credentials. This is an extension to role-based authorization and provides a more fine grained approach. This approach will typically be used with issue token authentication.                      
3)       Resource base: Here resources, such as WCF services, are secured using Windows Access Control Lists (ACLs).
There are three options when deciding how to determine a user’s role:
1)       Windows groups: You can use the built-in Windows groups such as Administrators or Power Users or create your own Windows groups
2)       Custom roles: You can create roles that are specific to your application, such as Manager, Employee, Administrator, etc.
3)       ASP.NET role management: You can use the ASP.NET role provider and use roles you have defined for a Web site.
In next article on this ,we will see how the various WCF security scenarios can be implemented practically
References:


No comments:

Post a Comment