Data Entitlement in an API-Centric Architecture 04/02/2015 Nuwan Bandara Senior Technical Lead

Entitlement in general John doe need to reed web page John authenticates with the system System checks John’s role and associated permissions If allowed john is presented with the page traditional application authenticate authorize access

API Centric Entitlements John doe need to reed resource foo John authenticates with the system System checks John’s role and associated permissions If allowed john is presented with the resource API Gateway authenticate authorize access

Common Aspects of the typical use case Involvement of a actor (john) Involvement of a resource (page / data) Use of permissions Use of an attribute (role) Involvement of an action (READ)

Entitlement complexities Complex rules Too many combinations Over time maintenance nightmare (a role per user / too many granular permissions) Too many changes (governance nightmare) Application centric

Who should provide entitlements Classic Use Case Access to ALL sales data Sales Managers Sales Database Sales T eam A DB Sales T eam B Whoshould provide Entitlements? Access to only sales data> belonging to> specific sales> group Application Y Application X

Traditional design Entitlements Repo Presentation Data exchange (1) (2) (6) (3) Request for permitted> access Data Access Layer Query Data Responsewith Fil ter MetaFdata (5) (4) Authori zed Items Reques t for da ta Fil tered Data Entitlements System Business Application

Where does the rules exist ? At the application layer ? At the API layer ? At the data access layer ? application API gateway data services

Modern entitlement design principals Re-usability Application / API neutral Loosely coupled to the underline system Centrally manageable performance

Data entitlement at the data access layer Conceptual SOA driven Data Entitlements Query- Based on User attribute- (i.e. Role) User Group A Request Entitlements Store Response User Group B Request for FilteredData Response Application B Data Service Application A Entitlements Service Data- Access- Service Filter Builder

Challengers Externalized entitlement engines are often seen as an unnecessary task and an overhead Needs fresh thinking and often re-writing the applications / APIs in a permission agnostic manner Must be standards driven Need to optimize for performance

Benefits Benefits are more long term Helps organizations adapt to changing business needs, and data security requirements easier Centralized management of platform level policies Ideal for heterogeneous systems – Unified access model to entitlements data Service mindset – everything is a service, including entitlements

Entitlements at the API Layer application api gateway entitlement engine data services authenticate authorize data access

Whats new in entitlement with regard to APIs APIs has define interactions (GET/PUT/POST/DELETE etc) APIs has token based authentication APIs has associated concepts (throttling / billing ) APIs are typically centrally managed

Entitlement patterns for API architectures Attribute based access control User Doe can READ resource Foo Policy based access control User Doe can READ resource Foo only 10 time per day

Entitlement policies and decision engines XACML is the standard for policy based entitlement XACML provides the rich entitlement rule authoring capability XACML policies are evaluated on a decision engine XAML has a defined sequence in integration to applications and APIs PEP / PDP / PAP / PIP Data service Requester PEP (Policy Enforce. Point) XACML Request XACML Response Manage XAML Policy (Policy Retrieval Point – PRP) Policy Store Attribute Store PIPB(PolicyB InformationB Point) PDPB(Policy DecisionBPoint) PAPB(PolicyB AdministrationB Point)

Putting it all together Enterprise User Store DB XACML Policy Entitlements Mediator (2) XACML request (1) App A Request + wsse:UsernameT oken (3) XACML responseB with Advices getSalesInfo App B (4) Build dynamic query Using advices (claims) fault Response (5) getSalesInfo + entitlements based filtering (7) Sales Datastore (6) Filtered Response App X DB PEP Dynamic Query DSS PAP PIP PDP IS

API gateway flow for authorization Entitlements Y es Permit? Query No Return Fault Send Response Call Data Service Build Dynamic Extract Claims Call Mediator Authenticate User

Sample policy ator AttributeId="http://wso2.org/claims/rol :xacml:1.0:subject-category:access-subject" 2001/XMLSchema#string" MustBePresent="true"> n> ="Rule1"> e" uteDesignator> In this exampleweareenforcingthat3 employeerole(a PIPentry)is3 embeddedon to theXACMLresponse XACMLPolicyrulesetgoes3 here(omitted)

Summary Data entitlement is central to an API architecture Entitlement rules needs to be loosely coupled to the API runtime Entitlement engine has to be capable to evaluating granular rules Data access has to be controlled via an entitlement engine as the permutation and combinations for data access can grow massively over time

Thank You