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