Security Implementation in RESTful

Security Implementation in RESTful Web Service :

We can implement the Security in various in Web Service Context  . Authentication and Authorization are the Key Factors for Security. Authentication mainly used to check the user credential  to make that user are authenticated and Authorization to make sure whether user has the access for those resource . Both are managed by Active directory access through LDAP .

Implementing the Security in RESTful in following ways

1)      Basic Authentication

2)      Digest Authentication

3)      CERT Authentication

4)      App key Authentication

5)      O Auth2.0

6)      Algorithm to generate the Passwords

Basic Authentication :

Authenticated the User Credential (User name and Password) pass as the plain text and it will validate against the Active Directory . if its valid then they can able to access the Service/Resource. Password Should be in Plain Text format.Credential pass as plain text from client to server  , server will validate and send back to Client . All the calls Http/Https.

Digest Authentication :

Similar to Basic Authentication , in addition password will stored in encrypted format , ie various hasing algorithm used to generate the encrypted password. Once we lost the password ,not possible to revert back to original . It’s the main constrain in Digest Authentication .

CERT Authentication :

Apart from User credential , We have CERT from CERT authority . CERT Authentication , we have keys to exchange during the communication . CERT will be Self-sign /Wildcard sign and etc. During the Client àServer Communication , SSL Handshake will happen and once its success then only allows to access the service/resource.

SSL Communication either its one way SSL/two way SSL . One way SSL , we are maintaining the CERT in Server side along with Public Key and Private key will managed by Client . Procurement of SSL CERT is different process, while procuring the CERT we need to pass the Client info, private and public keys. CERT must hold the Client Detail/Expiry Date /etc. In the Two way SSL , separate CERT will managed in Client and Server side .

Process SSL Hand Shake :

1)      Client access the URL from the browser, it will send to Client Hello to Server along with

2)      Server send the Server Hello to Client along with  CERT  

3)      Client Verify the CERT among the various CERT agent

4)      Client Send the pre master secret is encrypted inside the CERT to Server

5)      Server decrypted the master in CERT where server has the decrypted key

6)      Here both server and client have pre master and calculated the master secret to use the symmetrically encrypted and decrypted data between them

Two key SSL process is similar to one way except managing the separate CERT in Client  .

API Key Authentication/HMAC  :

It’s mainly used to integrate with other service/application . Ex: Service A will integrate with Service B , Service B should validate the request to make sure its from Service A.Service B will generate the App Key and App Id for Service A and share those information with Service A. Whenever Service A consume the Service B send those Appi ID and App Key along with user credential . User credential should encrypted before send to Service B. Once Service B Receive the request , it will check the App Id and App Key to make sure its valid with valid time frame. Then Service B validate the User credential . If all the valid then it will give access to service A otherwise it will return the error .

Algorithm to generate the password, We have MD5,SHA and etc are the algorithm to generate the encrypted password. Once its encrypted it will not back to original form .

OAuth2.0 Flow :

It’s mainly used to grant allows to third party application/services to HTTP Service . In our context we are integrating our services with eNets Services. Both are RESTful services . We are exchanging the token between two system while integrating /accessing services from there.

Roles in OAuth 2.0

Resource Server

Resource Owner

Client

Authorization Server

Types of Token

Access Token

Refresh Token

Note :

·         Communication between the two should HTTPS only in OAuth  Context since we are passing sensitive data between the two services and should be encrypted .

·         Client should register before accessing the application/services. Ex: Singtel should register into eNets before we consume their services/application .

·         Information need for registration

o   Application Name , Ex; Onepay

o   RedirectionURL ex: SuccessURL/Failure URL , if its valid then it will redirect to our success URL otherwise it will redirect to Failure URL

o   Grant Type

Grant Types

4 types of Grant Type in OAuth context.

Authorization Code Grant Type	In this case , Client as web service needs some user profile from Google/Face Book Resource Owner: Singtel Web server Resource Server: Google Server/FB Client : Service Authorization Server: Google/FB
Implicit Grant Type	Resource Owner: Singtel Web server Resource Server: Google Server/FB Client : javascript/JS Authorization Server: Google/FB
Resource Owner Password Grant Type	Resource Owner: Singtel OnePay Account Resource Server: API from eNets Client : Singtel One Pay Service Authorization Server: eNets Server
Client credential Grant Type	Resource Owner: any Site Resource Server: Google Server/FB Client : Any Site Authorization Server: Google/FB Here Resource Owner and Client are same

In our context we are following type 3 approach to integrate our services /api with eNets services.

Process :

11)     One Pay access the API from eNets , OnePay sends the user credential to eNets authorzation server

22)    eNet’s AS validate the credential and return the  authorization code to Singtel

33)   OnePay send the Authorization code to get the Access token
 3.a) Send the access token along with request to eNets Resource Server to access the API

44)   RS will returns the response

3.b) if the access token is invalid then Singtel will send the request to AS to get the Refresh token . AS will provide the Refresh token for further access.