Bring Your Own IDentity (BYOID) vs Take Your Own IDentity (TYOID)

There are many places that talk about Bring Your Own IDentity (BYOID) - but quite rare they talk about Take Your Own IDentity (TYOID). What is the difference or both having the same meaning?

Both look almost the same. The difference lies on how you look at it.

BYOID is relying party centric - while TYOID is identity provider centric.

Let me explain this bit more.

If you have an Identity Management system that supports BYOID, that should be able to mediate different heterogeneous identity protocols and standards. To elaborate more on that, you should let people authenticate with their own Facebook credentials (OAuth 2.0), Twitter credentials (OAuth 1.0), Google / Yahoo credentials (OpenID), Salesforce credentials (SAML 2.0) and many more. The overall credential management and mapping cost is at the relying party end.

If you have an Identity Management system that supports TYOID - its identity provider centric - and you need not to rely on the capabilities of the relying party Identity Management system. Say, you got to talk to a partner system that only knows SAML based authentication. The partner service will trust your SAML IdP. When the users from your domain, want to authenticate - they will be redirected to your own IdP. Now, the users can login to the SAML IdP with their Kerberos credentials - and authenticate to the partner service via SAML.

Here, the partner service supported BYOID - by trusting the SAML2 IdP of an out side domain - and at the same time - the local Identity Management system of the out side domain supported TYOID by letting its users authenticate with their own Kerberos credentials. Similarly, it could also let users authenticate with any format of internal credentials or any social login.

BYOID with WSO2 Identity Server

Enterprises grow today with acquisitions, mergers and partnerships. Integration between systems that were never designed to work together is harder.

Recently we integrated WSO2 App Factory with Codenvy - so you can use Codenvy as the cloud IDE for the projects created and managed in WSO2 App Factory. The integration was quite easy - as both the sides supported OAuth. Codenvy could act as an OAuth client, while WSO2 App Factory, as the OAuth authorization server. With this, Codenvy let WSO2 App Factory users to use their own identities from WSO2 domain and log in.

Life is not easy as this always.

We have also met customers who had the requirements of integrating heterogenous identity management systems together. Once the company Foo created a partnership with the company Bar, the Bar users coming from its own user store should be able to access the applications hosted in company Foo. The challenge is, applications in company Foo, do not know how to talk to the user store in company Bar. Ideally we should let the users from company Bar to bring their own identities.

If we are to change either of the side - then, the cost is quite high. Enterprises today, are looking for solutions that could mediate heterogeneous identity protocols - that would permit 'Bring Your Own Identity (BYOID)'.

WSO2 Identity Server is capable of supporting BYOID with Chained Collaborative Federation (CCF) pattern.

Identity Server can mediate identities between OpenID, OAuth 1.0, OAuth 2.0, SAML 2.0 and OpenID Connect - and has an extensible architecture to extend to your custom needs.

Social login is also a key part in BYOID.

Most enterprises let customers and even the employees associate their social logins with the corporate credentials. In that way, they can bring the social identity, in to the enterprise.

WSO2 Identity Server, has the capability to support OpenID association with its released version (so you can integrate your Google account) and in the future releases we are planning to add seamless integration with Facebook, Twitter and LinkedIn accounts.

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.

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.

The open source Identity Server which powers Saudi Arabia National Unemployment Assistance Program with 4 Million Users

In Saudi Arabia, ELM is a trusted provider of secure electronic services. Providing deep expertise in innovative and specialized e-services for government transaction and e-government initiatives, it is the first company in Saudi Arabia to have successfully launched a fully compliant e-government process.

In 2011, the Unemployment Assistance Program project launched to provide an allowance for all Saudi citizens who were currently unemployed and searching for a job. ELM had implemented the system, which included a portal where citizens could submit their requests, as well as applications running in the background that managed all the processes for qualifying the users and handling any payments. Initially, the project just covered one program.

However, a year later, as the Saudi government expanded services to include several programs, ELM recognized the need to streamline the administration for managing the user identities of everyone involved with the program. Recently ELM architected and implemented a system to manage a range of processes for the Saudi national Unemployment Assistance Program. Today, ELM relies on WSO2 Identity Server to manage some 4 million users of the Unemployment Assistance Program and ensure secure online transactions.

Interested in finding more..? Read this case study....