axiomatic s

7/28/2019 Axiomatic s

1/36

Privilege Management &

Attribute Based Access Control

Finn Frisch, CISM

Axiomatics AB


2/36

Focus on Entitlement Management

Attribute Based Access Control

Risk Intelligent Access Control

Research spin-off from the Swedish Institute of Computer Science

R&D team working since 2000

Company Axiomatics founded in 2006

Strong commitment to OASIS XACML TC

OASIS members since 2005

Axiomatics CTO is the editor for XACML 3.0

Products implementing XACML 2.0 and 3.0

Technology provider for some of the worlds largest XACML deployments

Axiomatics in Brief


3/36

Privilege Management vs. Entitlement Management

Potential Terminology Confusion

FoundationMapping People to Resources

The Access Matrix

Roles vs. Rules

IAM & GRC

Identity & Access Management (IAM)

Governance, Risk & Compliance Management

(GRC)

Policy Based or Attribute Based Access Control

(ABAC) Entitlement ManagementABAC + GRCthe Paradigm Shift

An Attribute Management Framework

Todays Topic How Manage Privileges With ABAC


4/36

Axiomatics definition of Entitlement Management

Managing Privileges or Permissions

Who should begranted access to

which information

assets where, when,

how and why and

how is it controlled?

Entitlement vs. Privilege Management

External to

Applications

Standards-

Compliant

Fine-

Grained

Context-

Aware

Authorization Service


5/36

The Access Matrix

Static, predefined and preconfigured mapping of user to resources

User Res1 Res2 Res3 Res4 Res5 Res6 Res7 Res8 Res9

Joe X X X X X

Anne X X X X

Robert X X X X

Susan X X X X X

Ian X X X

Mary X X X X X

Keith X X X X X X X


6/36

Grouping Permissions

Grouping permissions to simplify administration

User Res1 Res2 Res3 Res4 Res5 Res6 Res7 Res8 Res9

Joe X X X X X

Anne X X X X

Robert X X X X

Susan X X X X X

Ian X X X

Mary X X X X X

Keith X X X X X X X


7/36

Grouping permissions Bottom-upGrouping job tasks, functions Top-DownBut still:

Static, predefined and preconfigured

The Role Concept

Res1 Res2 Res3 Res4 Res5 Res6 Res7 Res8 Res9

X X X X X

X X X X

X X X X

X X X X X

X X X

X X X X X

X X X X X X X


8/36

Static, predefined and

preconfigured

Enforcing

Segregation of Duties (SoD)

An example


9/36

Visibility

Maturity

Technology

trigger

Peak of Inflated

Expectations

Trough of

Disillusionment

Slope of Enlightenment Plateau of

Productivity2005

?

2006

2007

2008

2009

SoD Within ERP Gartner Hype Cycles 2005-2009


10/36

SoD Within ERP Gartner MarketScope 2006-2009


11/36

Business risks due to SoD conflicts


12/36

RBAC the Never Ending Sudoku

Users

Roles

Permissions

Removing conflicting

permissions from Role 1

and/or Role 2 may solve

problem for user group 2

but create new problems for

user group 1 and 3.

Role 1 Role 2

SoD

violation

1 2 3


13/36

Cross-application SoD the Sudoku nightmare

Role A1 Role A2

SoD

violation

GrA1 GrA2 GrA3

Role B1 Role B2

SoD

violation

GrB1 GrB2 GrB3

SoD

violation

Application A Application B


14/36

Business Manager

We need to enforce

SoD on functions

that allow users to

Create and Maintain

Vendor Master Data

while also being able

to Create and

Release Purchase

Orders

What?

SoD and Communication Challenges

IT Manager

What?

Who should have access to

transaction XD01?


15/36

Business Manager

We need to enforce

SoD on functions

that allow users to

Create and Maintain

Vendor Master Data

while also being able

to Create and

Release Purchase

Orders

SoD and Communication Challenges

TopDown

Perspective

Bottom

Up

Perspective

IT Manager

Who should have access to

transaction XD01?


16/36

IAM & GRC


17/36

Identity & Access Management Common Vision


18/36

Ordering user permissions in a structured process

Create, Alter or Delete

Approval by authorized managers

User provisioning for

deployment

Reporting for

regular recertification

and auditing

Identity & Access Management Governance


19/36

Built on the assumption that privileges can be predefined and

preconfigured as static mappings between users and their information

assets!!

User Provisioning


20/36

Rule Based Concepts


21/36

XACML offers a generic standard for rules based on attributes of:

Subject

Action

Resource

Environment

Policy-based / rules based access control is becoming a reality on a

broad scale

Dynamic, real-time assignment of user privileges

The paradigm shift standards based ABAC


22/36

User U can access resource R

BeforeStatic mapping of

User U to Resource R

(with or without roles)

U ------ R

AfterRule example:

IF

(Us department=Rs department)

THEN Permit else Deny

U.dept=xyz & R.dept=xyz

Thus permit!


23/36

ABAC beyond RBAC

Role 1

Role 2

Role 3

Role 4

UserRolePermissions User + Action + Resource + Context

Attributes

Role-Based Access Control Attribute-Based Access Control

Policies/Rules

Subject Action Resource Context

A user wants to do

something

with an

information asset

in a given context or

environment

Examples:

A medical

doctor

wants to open

and edit

a patients health

record

in the hospitals

emergency room at 3 p.m

A banks

client

wants to withdraw

300

from an

account

via an ATM machine in X

city


24/36

XACMLa standard for access control policies

An abstract architecture

A policy language, and

A query-response protocol

Developed within OASISCurrent Version is 2.0 but Axiomatics also implements the

3.0 Working Draft to be approved in a near future adding Delegation of

Administrative Privileges

Broad support by the industry

The only standard for access control policies

XACML Technology Overview


25/36

XACML Components and Architecture

Application 1

User A

Application 2

User B

Administration

Point (PAP)

Administrator

Policy Enforcement Point (PEP)

Captures access requests in an application andexpresses them in XACML using descriptive attributes

Policy Decision Point (PDP)

Responds to access requests based on XACML

policies and rules - permit or deny

Policy Administration Point (PAP)

Administration GUI for maintenance of policies

Policy Information Point (PIP)

Services providing additional information to help

resolve an access request from a PEP in caseswhere complimentary data is needed

AD

LDAP(PIP)

Policy

Repository

PAP

PIP

PEP

PDP

Information assets/Data

XACML

Policy

XACML

Request/

Response


26/36

ABAC and Governance?

Enforcing SoD?

Approval workflows for privilege assignments?

Reporting on actual user permissions?

Certification procedures?


27/36

Policy / rule definitions (rarely updated)

Attribute values describing

Subjects

Resources

Actions

Environment

(maintained in day-to-day operations)

Permissions granted via ABAC


28/36

Role 1 Role 2

SoD

violation

1 2 3

Approve

payments

Edit vendor

master data

If action=approve

resource=payment

subject has a Drivers License

then permit else deny

DriversLicense

Manipulated vendors:1) Fake company

2) My company

3) My cousins company

Approve payment

SoD

violation

BILLfrom

Fake Corp.

RBAC ABAC

Segregation of Duties RBAC vs. ABAC

Signature

Permissions

Users

Roles

Edit vendor

master data


29/36

Approve paymentsEdit vendor master data SoD Enforcement

BILLfrom

Company Z

My manipulated

vendors:

1) Company A

2) Company B

Approval banned

BILLfromCompany A

Approval

permitted

X

OK

IF

action=approve

resource=payment

payment.recipient not in subject.manipulated_vendors_list

THEN Permit else Deny

Context aware authorization

Mitigating controls built

into a policy-based

authorization system


30/36

Secure authentication of subjects is a prerequisite for ABAC but

outside the scope of ABAC itself

ABAC relies on robust Identity Management for attribute lookup

No provisioning can be made to

the rules engine itself

User Provisioning and ABAC

Administration

Point (PAP)

Administrator

Application 1

User A

Application 2

User B

AD

LDAP

(PIP)

Policy

Repository

Information assets/

Data

XACML

Policy

XACML

Request/

Response


31/36

Attribute Management

Framework


32/36

Infrastructure with data sources

Conceptual solutin

Best practices

Methods

Technology

New foundation: Attribute Management Framework

PIP interfaceAttribute Management Framework


33/36


New foundation: Attribute Management Framework

Application 1

User A

AdministrationPoint (PAP)

Administrator

Policy

Repository

PIP interface

XACML

Policy

Attribute Management Framework

AMF

Data

Attrib Mgmt

Approval WF

Application 2

User B

XACML

Request/

Response


34/36

Other sources

Existing IAM-UP Governance

Customers already have an infrastructure

Re-using SAP roles to manage access to document store

Additional attributes about documents and users are needed

SAP role management complies with corporate governance rules

Other attributes are being reused for a new purpose

Real-world scenarios

Documents

AMF

SAP Roles

HR Mgmt level

AD Dept code

PPM Project

member

Read-only

Change-mgmt & QA:

Logging updates for

traceability

Possible approval

workflow before

update is committed

Authoritative source for

attributes used by ABAC


35/36

Basically three types of attributes:

Newneeded to express necessary rules

Existing trusted attributeslike SAP roles already used for

authorizaation and maintained with solid governance

Existing but possibly not trusted attributes reused for

authorization although they currently are being maintained for

other purposes

An authoritative source for source attributes

Attribute Management Framework


Trusted and

maintained -imported

Not trusted

approvalrequired

New

maintainedwithin ABAC


36/36

Questions?

Discussions?

For more information, dont hesitate to contact me:

[email protected]