Tuesday, December 3, 2013

Fine-grained Access Control for APIs

OAuth is the de facto standard for API security and it's all about access delegation.

The resource owner delegates a limited set of access rights to a third party. In OAuth terminology, this is the “scope”. A given access token has a scope associated with it and it governs the access token’s capabilities.

XACML (eXtensible Access Control Markup Language) is the de facto standard for fine-grained access control. OAuth scope can be represented in XACML policies.

Say, for example a user delegates access to his Facebook profile to a third party, under the scope “user_activities”. This provides access to the user's list of activities as the activities connection. To achieve fine-grained access control, this can be represented in a XACML policy.
<Policy>
     <Target>
          <Anyof>
                <AllOf>
                     <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                         <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
                                user_activities
                         <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:scope:scope-id" category="urn:oasis:names:tc:xacml:3.0:attribute-category:scope" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="false">
                      </Match>
                </AllOf>
         </AnyOf>
    </Target>
    <Rule Effect="Permit" RuleId="permit_rule">
    </Rule>
    <Rule Effect="Deny" RuleId="deny_rule">
    </Rule>
</Policy>
The above policy will be picked when the scope associated with the access token is equal to user_activities. Authorization Server first needs to find all the scopes associated with the given access token and build the XAML request accordingly. Authorization Server first gets the following introspection request.

token=gfgew789hkhjkew87
resource_id=GET https://graph.facebook.com/prabathsiriwardena/activities

Authorization Server now needs to find the scope and the client id associated with the given token and build the XACML request.
<Request>
      <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:oauth-client">
           <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:client:client-id">
               <AttributeValue 
                     DataType="http://www.w3.org/2001/XMLSchema#string">32324343434</AttributeValue>
          </Attribute>
     <Attributes>
    <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
         <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
             <AttributeValue
                     DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
        </Attribute>
    </Attributes>
    <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:scope">
       <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:scope:scope-id">
              <AttributeValue  
                      DataType="http://www.w3.org/2001/XMLSchema#string">user_activities</AttributeValue>
       </Attribute>
    </Attributes>
    <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
        <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
              <AttributeValue 
                      DataType="http://www.w3.org/2001/XMLSchema#string"> 
                                       https://graph.facebook.com/prabathsiriwardena/activities</AttributeValue>
        </Attribute>
    </Attributes>
</Request>
The above request will pick the policy we defined first and evaluate the rules. Each rule can define the criteria, whether to permit or deny.

  1. User / System accesses the API passing an access token.
  2. API Gateway intercepts the request - finds the access token and calls OAuth Authorization Server (Introspection endpoint) to validate it. 
  3. Authorization Server, finds the scopes and the client id associated with access token, builds a XACML request can call XACML PDP. 
  4. XACML PDP evaluates the XACML requests against its policy set and returns back a XACML response. 
  5.  OAuth Authorization Server sends back a Introspection Response which indicates the validity of the token. 
  6. API Gateway validates Introspection Response and then invokes the backend business API.

Monday, December 2, 2013

Enterprise API Access/ Security Patterns

Accessing an API secured with OAuth, on behalf of a user logged into the system, with SAML2 Web SSO.

  1. User from domain Foo tries to access a web app deployed in domain Bar. The web app is secured with SAML2 Web SSO. 
  2. Web App finds user does not have an authenticated session. Finds out from the which domain the request was initiated from and redirects the user to the SAML2 IdP in his own domain. 
  3. User authenticates to the SAML2 IdP in his own domain. 
  4. SAML2 IdP from domain Foo sends a SAML response back to the web app in domain Bar. 
  5. Web app validates the SAML response. It has to trust the domain Foo SAML2 IdP. To access backend APIs - on behalf of the logged in user, web app needs an OAuth access token. Web app talks to the OAuth Authorization Server in its own domain, passing the SAML token. 
  6. OAuth Authorization Server trusts the SAML2 IdP in domain Foo. Validates the SAML token and sends back an access token. 
  7. Web app invokes the API with the access token. 
  8. API Gateway intercepts the request - finds the access token and calls OAuth Authorization Server to validate it. 
  9. OAuth Authorization Server validates the token and sends back a JWT (JSON Web Token) which includes end user details to the API Manager. 
  10. API Gateway adds the JWT as an HTTP header and invokes the backend business API. 

Accessing an API secured with OAuth on behalf of a user/system authenticated to a SOAP service with WS-Trust.

  1. User / System from domain Foo authenticates to the WS-Trust STS in his own domain. 
  2. STS returns back a SAML token to access the SOAP service in domain Bar. 
  3. User/System authenticates to the SOAP service in domain Bar with the SAML token. 
  4. SOAP service validates the SAML token. It has to trust the domain Foo STS. To access backend APIs - on behalf of the logged in user, SOAP service needs an OAuth access token. SOAP service talks to the OAuth Authorization Server in its own domain, passing the SAML token.
  5. OAuth Authorization Server trusts the STS in domain Foo. Validates the SAML token and sends back an access token. 
  6. SOAP service invokes the API with the access token. 
  7. API Gateway intercepts the request - finds the access token and calls OAuth Authorization Server to validate it. 
  8.  OAuth Authorization Server validates the token and sends back a JWT (JSON Web Token) which includes end user details to the API Manager. 
  9. API Gateway adds the JWT as an HTTP header and invokes the backend business API. 
 Fine-grained access control with XACML.

  1. User / System accesses the API passing an access token.
  2. API Gateway intercepts the request - finds the access token and calls OAuth Authorization Server to validate it. 
  3. Authorization Server, finds the scopes and the client id associated with access token, builds a XACML request can call XACML PDP. 
  4. XACML PDP evaluates the XACML requests against its policy set and returns back a XACML response. 
  5.  OAuth Authorization Server sends back a JWT (JSON Web Token) which includes end user details to the API Manager. 
  6. API Gateway adds the JWT as an HTTP header and invokes the backend business API.