Security and REST
If you look into the above code, you will noticed the flaw, this service does not have any security aspect built into it. But when we are building services exposing endpoints, the security aspect should be taken care of. RESTful services are just HTTP endpoints, so all security aspects implemented with HTTP (like HTTPS, certificates) can also be implemented with REST.
There are two types of hosting services, self hosting Web Services and Web Services hosted with an application server like IIS. In self hosting Web Services, most of the security aspect should be taken care of in the code; on the other hand, while hosted in IIS, the setting in IIS take care of the security.
Setting Endpoint: Security for Self Hosted
Security of the end point is set by the Security property of WebHttpBinding. The Security property is of type WebHttpSecurity and is used to determine the security mode required by the binding and the type of client credentials it requires. There are two properties of WebHttpSecurity: Mode (of type WebSecurityHttpMode) and Transport (of type HttpTransportSecurity). There are three levels of security that can be specified using WebHttpSecurityMode:
None
Transport
TransportCredentialOnly
WebHttpBinding.Security.Transport which is of type HttpTransportSecurity helps to authenticate the client. It has these three properties:
ClientCredentialType (of type HttpClientCredentialType)
ProxyCredentialType (of type HttpProxyCredentialType)
Releam (String)
Values for HttpClientCredentialType can be any one of the following: None, Basic, Digest, NTLM, Windows, Certificate.
Setting Endpoint: Security for Services Deployed on IIS
When hosting an endpoint on IIS, use the web.config file to make configuration changes. The configuration can be done for the virtual directory where the service is running. We need to be aware of both the client config and the virtual directory configuration.
Authorization
Once authenticated, the next step is to authorize the client, what they can do and what they can't do.
Impersonation: by impersonating the client, the authorization is delegated to another layer. For example, when a client is trying to insert or update data in to a SQL Server database, SQL Server throws an exception in case the client doesn't have permission, which can be bubbled back to the client.
Role based: Implement authorization by restricting access to operations to certain Windows users or groups.
Source Collected from Code Project
No comments :
Post a Comment