1. Data Entitlements
with the WSO2 Enterprise Middleware Platform
Manoj Fernando
Director - Solutions Architecture

2. About WSO2
• Providing the only complete open source componentized
cloud platform
–
–
Dedicated to removing all the stumbling blocks to enterprise agility
Enabling you to focus on business logic and business value
• Recognized by leading analyst firms as visionaries and
leaders
–
–
Gartner cites WSO2 as visionaries in all 3 categories of
application infrastructure
Forrester places WSO2 in top 2 for API Management
• Global corporation with offices in USA, UK & Sri Lanka
–
200+ employees and growing
• Business model of selling comprehensive support &
maintenance for our products

3. 150+ globally positioned support customers

4. Agenda
•
A Classic Use Case
•
Need for Data Entitlements
•
Data Entitlements - A Traditional Approach
•
Challenges and benefits
•
Features provided by WSO2 Identity Server
•
XACML – Policy Based Access Control
•
Using WSO2 Middleware Platform to implement our sample use case
•
Mediator Flow
•
Summary
•
Q&A

5. A Classic Use Case
Access to ALL sales data
Sales
Managers
Sales Database
Application X
Sales Team A
DB
Application Y
Sales Team B
Access to only
sales data
belonging to
specific sales
group
Who should provide
entitlements?

6. Need for Data Entitlements
•
A responsibility shared between business logic and data layers?
•
Use cases often talk about permissions, so who should handle it?
“User with permission X has to be able to read and modify asset Y”.
•
But many would agree with the idea of globally manageable application
permissions.
•
Permissions are not just based on user roles (anymore).
•
Growing demand for a unified entitlements framework for all types of
applications.

7. Primary Purpose
Is to provide total transparency to multiple applications
when accessing shared assets, so that enterprise-wide
data access policies will take effect at the point of data
being queried or manipulated by users.

8. Data Access Layer – a place for data entitlements?
•
Primary purpose is to provide loose
coupling between data and
application logic.
•
Data Access components are
language specific, hence it falls short
to meet the exact expectation on
enterprise entitlements within a
heterogeneous environment.
Business Application
B
A natural choice to place data
entitlements logic.
•
Business Application
A
•
No standard as such to govern
enterprise-wide entitlements policies
when using DAL.
Data Access Layer
Permissions
Data
Enterprise
Data

9. Data Entitlements – A Traditional Approach
Business
Application
Data exchange
Authorized Items
(2)
Request for data
(1)
Filtered Data
Presentation
Entitlements
Repo
(6)
(3)
Data
Query
(5)
Data
Access
Layer
Request for permitted
access
Response with Filter
Meta-data
(4)
Entitlements
System

10. Challenges in putting up an Enterprise Data
Entitlements System
•
Often viewed as an unnecessary task, specially when system designers tend
to think around ‘siloed’ applications.
•
Usually requires a significant amount of ‘re-wiring’ to the permissions
handling logic of existing applications.
•
Must be driven by standards!
•
Some believe that using an external entitlements system is
counterproductive in maintaining ‘lightweight-ness’ of the applications.
•
No SOA, No use of data entitlements?

11. Benefits
•
Usually the benefits are more long term than short 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.

12. Is SOA/Middleware the foundation for Data
Entitlements?
•
Seldom you will see that an enterprise using applications developed on a
single technology.
•
SOA brings the real power of data entitlements into the platform by
providing standards driven, loosely coupled architecture.
•
Works well with other cross cutting requirements such as enterprise
logging, transport and message level security, etc.
•
A key enabler for cross-application integration scenarios.

13. A Conceptual SOA driven Data Entitlements
Entitlements Query
Based on User attribute
(i.e. Role)
User
Group A
Request
Application
A
Data
Access
Service
Entitlements
Service
Entitlements
Store
Response
User
Group B
Filter
Builder
Application
B
User
Group X
Request for Filtered Data
Data
Service
Response

14. Building an entitlements system with WSO2 Identity
Server - Features
•
Provides a fully fledged Policy Based Access Control (PBAC) platform.
•
Fine-grained policy based access control via XACML
•
Advanced entitlement auditing and management
•
Entitlement management for any REST or SOAP calls
•
Role based access control (RBAC)

15. XACML – Terminology
XACML stands for eXtensible Access Control Markup
Language.
Policy Enforcement Point (PEP)
• Point which intercepts user's access request to a resource, makes a
decision request to the PDP to obtain the access decision (i.e. access to
the resource is approved or rejected), and acts on the received decision.
Policy Decision Point (PDP)
•
Point which evaluates access requests against authorization policies
before issuing access decisions

16. XACML - Terminology (Cont…)
Policy Administration Point (PAP)
• Point which manages access authorization policies
Policy Information Point (PIP)
•
The system entity that acts as a source of attribute values (i.e. a resource,
subject, environment, etc.)
Policy Retrieval Point (PRP)
•
Point where the XACML access authorization policies are stored, typically a
database or the file system.

17. XACML - Policy Based Access Control (PBAC)
•
•
•
•
Fine-grained access control
policies based on subject,
resource, environment and
action attributes
Portable and reusable policies
enforceable across multiple
platforms
All aspects of access request
are identified by attributes
Optional Rules Engine
Integration
Requester
PEP
(Policy
Enforce.
Point)
XACML
Request
XACML
Response
PDP
(Policy Decision
Point)
XAML Policy
(Policy Retrieval Point –
PRP)
Policy
Store
Data service
PAP
(Policy
Administration
Point)
Manage
PIP
(Policy
Information
Point)
Attribute
Store

18. XACML 2.0/3.0 Support on WSO2 Identity Server
•
Policy decision processing and attribute caching
•
Policy distribution to various Policy Decision Points (PDPs)
•
Multiple Policy Information Point (PIP) support
•
Friendly UI for Policy editing (PAP)
•
High performance network protocol (over Thrift) for PEP/PDP interaction
•
Policy Administration Point (PAP) to manage multiple Policy Decision
Points (PDP)

19. Back to our sample scenario…
Access to ALL sales data
Sales
Managers
Sales Store
Application X
Sales Team A
DB
Application Y
Sales Team B
Access to only
sales data
belonging to
specific sales
group
How to leverage WSO2
middleware platform for this?

20. … and our requirement
•
Should provide a unified service interface for querying sales info
•
Caller applications need not worry about entitlements (they just query for
sales info).
•
The policy enforcer needs to acquire entitlements for a common user
attribute (i.e. username)
•
The policy decision maker should return the list of entitlements (or claims)
back to the enforcer.
•
The enforcer should build the data filtering logic based on the claims and
append that to the service call.
•
The filtered data set is returned back to caller.

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

22. ESB Mediation Flow
Authenticate
User
Call
Entitlements
Mediator
Yes
Permit?
Extract
Claims
Build
Dynamic
Query
No
Call Data
Service
Return Fault
Send
Response

23. XACML Policy – Making claims be passed with
Response
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="CustomerServiceSales"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
Version="1.0">
<Target></Target>
<Rule Effect="Permit" RuleId="Rule1">
…
</Rule>
<AdviceExpressions>
XACML Policy ruleset goes
here (omitted)
<AdviceExpression AdviceId="customerService" AppliesTo="Permit">
<AttributeAssignmentExpression AttributeId="employee.role">
<AttributeDesignator AttributeId="http://wso2.org/claims/role "
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"></AttributeDesignator>
</AttributeAssignmentExpression>
</AdviceExpression >
</AdviceExpressions>
</Policy>
In this example we are enforcing that
employee role (a PIP entry) is
embedded on to the XACML response

24. Claims to Data Service Filter
•
Claims received by the Entitlements Mediator exist in the MessageContext
object.
•
A Class Mediator can be used to extract these claims from the
MessageContext and construct the filter logic.
•
The ESB Sequence can thereby append the filter logic into a placeholder
for filtering (i.e. If you use WSO2 DSS, you can specify this placeholder as a
QUERY_STRING type, and use validation logic to avoid potential SQL
injection scenarios).

25. Summary
•
Middleware plays a pivotal role in establishing an enterprise grade data
entitlements system.
•
WSO2 Identity Server provides all necessary features to implement a fully
fledged data entitlements system supported by WSO2 ESB for mediating
the service calls, and WSO2 DSS for exposing your data as services.

26. Resources
Blog post
- http://manoj-fernando.blogspot.com/
References
- WSO2 Identity Server :
http://docs.wso2.org/display/IS450/WSO2+Identity+Server+Documentation
-
XACML : https://www.oasisopen.org/committees/tc_home.php?wg_abbrev=xacml

27. Q&A

28. Engage with WSO2
• Helping you get the most out of your deployments
• From project evaluation and inception to development
and going into production, WSO2 is your partner in
ensuring 100% project success

29. lean . enterprise . middleware