Securing Restful Services With Token Based Authentication Computer Science Essay

Securing Restful Services With Token Based Authentication Computer Science Essay Enterprises are increasingly deploying RESTful services for two reasons 1) to enable Web 2.0 integrations with data stores and backend systems 2) to allow RPC-style communication between client side web frameworks like GWT or YUI and backend systems. In addition, there are multiple frameworks to develop these services that are consumed internally and externally by different endpoints in different contexts. Hence, it is vital to provide simple and adaptable security that both integrates seamlessly with enterprise security and brings authentication, authorization and integrity to the services. This paper covers the pros and cons of various approaches of RESTful services security: 1) Transport level security (TLS/SSL) provides secure peer-to-peer authentication, but this technique is inadequate when requests for authentication are based on delegation (allowing sites to authenticate on behalf of the user). 2) The OAuth protocol enables consumers to access services through an API that doe s not require consumers to disclose their service provider credentials to access services. This is the most commonly followed approach used by Google AuthSub, AOL OpenAuth, and the Amazon AWS API. However, not all REST frameworks provide support to this protocol. 3) Token-based authentication developed for CA Technologies Unified Connector Framework (UCF) to expose services over REST or SOAP combines the advantages of these two without compromising standards and simplicity. Introduction Since RESTful web services are exposed using standard HTTP protocol and methods, they can easily be consumed in multiple ways, such as with direct access from browsers using URLs; through programmatic interface using HTTP client libraries; and from client side frameworks such as JavaScript,. If enterprise systems provide RESTful access to their data and functionality, the open nature of REST requires a strong security solution to prevent access by unintended users; to prevent sniffers on the network from reading messages; and to control the users who are allowed to interact with specific services and disallow certain actions for certain users. The question is what should be the strong security solution? The REST protocol itself does not specify any predefined security methods. Many people believe that HTTP security practices can be successfully applied for securing REST services. This can be true, depending on the scenarios where RESTful services are consumed. HTTP security may be ad equate if the RESTful services are intended for internal use only. One example is web applications using Ajax frameworks. Since they need RPC over HTTP or RESTful services for backend interactions, invocation of services is internal to the UI and transparent to clients who interact with the UI. In such a scenario, HTTP security may be adequate.. However, greater security is required when RESTful services are intended for external use, For example, CA Technologies Catalyst integration platform provides RESTful services that can be consumed by such mechanisms as mashups, ESBs, Ruby scripts, and many more, and requires a higher level of security. Although the security requirements greatly vary for these two scenarios, we need a simple and adaptable solution for both. This article describes the commonly used security methods for RESTful services and suggests a solution that mostly fulfills the security requirements for externally published services, including REST, SOAP over JMS, SOAP o ver HTTP, and other protocols. This approach was developed for and is used in the RESTful services of the Core API of CA Technologies Catalyst integration platform. Commonly available methods for securing RESTful services Container-Managed Authentication and Authorization: As RESTful web services are HTTP-centric, the most natural fit for authentication and authorization is container based authentication and authorization. The concept of realm places a central role in the Tomcat approach. A realm is a collection of resources including web pages and web services, with a designated authentication and authorization facility. The container approach to security also is declarative than programmatic that is details about the security realm are specified in a configuration file rather than in code. The container also provides option to enable wire level security. Refer [1] [2] for information about configuring realms for authentication and authorization and SSL/TLS for wire level security. The advantages of this method need not be specified explicitly here as they are proven and widely used. However, it has the following limitations when applied to RESTful services for enterprise use: With user credentials based authentication, the security solution is confined to identity silos. It does not support the Actas scenario. An Actas scenario involves multi-tiered systems to authenticate and pass information about identities between the tiers without having to pass this information at the application/business logic layer. Mutual Authentication: HTTPS with client certificate enabled performs two-way authentication. In addition to the client receiving a signed digital certificate representing the server, the server can receive a certificate that represents and identifies the client. When a client initially connects to a server, it exchanges its certificate and the server matches it against its internal store. Once this link is established, there is no further need for user authentication. Mutual authentication is perhaps the most secure way to perform authentication on the Web. This approach has the same drawbacks mentioned in the previous section. Another disadvantage of this approach is the managing of the certificates. The server must create a unique certificate for each client that wants to connect to the service. From the browser/human perspective, this can be burdensome, as the user has to do some extra configuration to interact with the server. Shared Key based authentication: This is the common method used by Amazon web services and Microsoft Azure services. In this method initially the client registers with the service provider. As part of registration, the service provider sends the client an Access Key ID and a Secret Access Key. When a client wants to invoke services, it prepares the request, performs a hash on the request using its Secret Access Key, attaches the signature (hash) to the request, and forwards it to the service provider. The service provider verifies the signature is a valid hash of the request and, if authenticated, processes the request ([3] [4]). This achieves requester authentication as well as integrity without SSL The problem with this authentication schemes is that the contents and ordering of the string to sign are different from one service provider to another service provider. For instance, though Amazons and Azures mechanisms are very similar, their differences make them incompatible. Perhaps due to this issue, the OAuth approach covered in the next section is gaining popularity as a standard security mechanism for RESTful services. OAuth Oauth is an open protocol allowing secure API authentication and authorization in a simple and standard method for web applications. OAuth allows users of a service to provide limited access to a third party account of theirs to the service without sharing credentials. OAuth is often described as a valet key that users can give to a service to access their accounts on other services. For example, a user of Flickr (the service provider) would provide Snapfish (the consumer) with read only access to their Flickr account. This lets Snapfish access photos in the users Flickr account so they can order prints. Refer [5] for more details about OAuth specification. OAuth has some distinct advantages: It doesnt require certificates By choosing the right token format, it can support claims based Token. A claim is a statement about a subject; for example, a name, key, group, permission, or capability made by one subject about itself or another subject. Claims are given one or more values and then packaged in security tokens that are distributed by the issuer. It supports the SAML token. SAML (Security Assertion Markup Language) is a standard for exchanging authorization and authentication data between between an identity provider and a service provider regardless of their platforms or security systems. OAuth with SAML enables federated authentication and authorization. The only drawback is that not all RESTful services frameworks provide native support for dealing with OAuth based authentication. For example, Apache CXF does not support OAuth. Token based Authentication CA Technologies Catalyst4 integration platform includes the Unified Connector Framework (UCF) that provides a Java-based solution for connectivity and integration among CA and third-party products UCF has distinct security requirements: It should be able to support Actas scenarios; the platform should be able to invoke services from 3rd party providers on the behalf of clients Catalyst exposes services in several different protocols, including RESTful, SOAP over HTTP, SOAP over JMS, etc. Its security solution should work consistently in all the forms of the services. Its security solution should be extensible, simple and adaptable in different scenarios. To accommodate these requirements, UCF introduced the token based security solution using public Key Infrastructure (PKI) certificate for authentication and authorization of its services. This solution has the following components:. Domain Trust Certificate (DTC) is an X.509 v3 certificate issued by a Certificate Authority (CA) or self signed owned by the DomainManager that controls the UCF domain. Trusted Certificate (TC) is a X.509 v3 certificate signed by DTC. A Node is either a service provider or service consumer who owns that TC signed by the DTC. Security Service is available per container2 which hosts several connectors1. This service issues a Token, validates the Token and sets claims retrieved from Token to the context so that they can be used by connectors or other entities in the container for Authorization or Actas scenarios. CertAuthService is an independent entity provides services like signing Certificate Signing Request CSR 5 and providing the DTC public key Token consists of set of claims signed by security service. Interactions on the Client side: The client generates a CSR (Certificate Signing Request) using keytool 6 and obtains a X.509 certificate signed by DTC from the CertAuthService. The signed CSR is called a Trusted Certificate (TC) in UCF domain. The client makes an addTrust() request to the Security Service at the service provider by passing its public key certificate. This step enables the Security Service to validate the certificate and add provided certificate to its trust store. Steps 1 2 are performed only once per client. The client makes a getToken() call with tokenRequest to the Security Service. The tokenRequest consists of claims and a signature computed using the clients private key. If client is using UCF API to make remote calls, then steps 1 2 are transparent to the client at the time of proxy creation to the service endpoint. The client prepares the request and adds the Token to the request header. If client is using the UCF API to make remote calls, then adding the Token to the request header is transparent to the client. The client makes a remote call Interactions on the Service side: The Security Service is hosted from a Catalyst container so that it is available to both external users and inside the container for security token validations. For addTrust() calls, the Security service validates the provided certificates signature to find whether it is signed by DTC or not. If it is DTC signed then the Service adds the certificate to its trust store. For getToken() calls, the Security service checks the signature against the available keys in its trust store. If it succeeds then a token is prepared and returned to the client. The token consists of claims, lifetime and the signature of the Security service. For all incoming calls to the services available in the Catalyst container, calls are intercepted at CXF handlers and the token is verified with Security service. If it is from a valid client then claims are extracted out of the token and sets to thread local context so that it may be used by connector implementation for further authorization or authentication with other service providers. Finally, the call is forwarded to the service. If the Security service is unable to validate the token, an unauthorized exception is returned to the client. Authorization is handled by any provider on service using claims. As described above, this solution supports authentication based on X.509 certificate and authorization is done by any provider using claims. The same set of claims is used for Actas scenario. For instance, services running in Catalyst container can use claims to talk to another services or endpoint on the behalf client. Conclusion The solution described in Section 3 is a better fit for platforms/products like Catalyst that need to make services available in more than one form such as REST, SOAP over HTTP and SOAP over JMS. It is a security solution that works consistently in all forms of services. Also, the solution is extensible to other modes of authentication like user credentials other than certificate based. This solution needs additional work to replace custom Token format to SAML based so that tokens can be consumed in third party software which understands SAML. This. Acknowledgments The solution described in Section 3 was contributed by entire UCF team which includes Sijelmassi, Rachid, me, GVN, Anila Kumar and Koganti, Naga. . Actas