WSO2Con USA 2017: Introduction to Security: End-to-End Identity Management

End to End Identity Management

Johann Dilantha NallathambyTechnical Lead

WSO2

Defining the Topic

1. Define Identity2. Define end-to-end3. Define Managing of Identities

Defining Identity

Simply,• Who am I?• What are my attributes?• What are my behaviours?• What are my relationships?

Defining End-to-End

Life of a single Identity over time

Defining End-to-End

Resource access by Identities at a given snapshot of time

Defining Management

Defining Management

I am an Engineer, not a manager!!

Let’s look at management in terms of challenges and solutions

Defining Management

I am an Engineer, not a manager!!

Let’s look at management in terms of challenges and solutions

Let’s look at the story of Bob

Beginnings of Bob’s journey ...

• Bob is a senior engineer• Bob is working for a startup called “X”• Bob is responsible for the Identity Management of his staff.• His company has a handful of employees• They have only a very few applications• Bob’s life was going good :)

Few years down the line ...

• Bob’s company was doing very well• They are now having a large number of employees after

rapidly expanding• They are planning to recruit even more• They now have several internal and cloud applications• Identity Management is becoming a headache for Bob!!

User accounts in all the systems

Robert(An employee)

Cloud email Service

Username = “robert”Password = “robert-pass”

Expense Management

SystemHR System

Username = “robert2”Password = “robert2-pass”Username = “robert2”Password = “robert2-pass”

Username = “robert_5”Password = “K67robert2-AB-#2”

Bob thinks why not a centralized user directory?

Bob has an idea in mind

Robert

Mail ClientUsername = “robert”Password = “robert-pass”

HR System

Expense Management

System

Username = “robert2”Password = “robert2-pass”Username = “robert”Password = “robert-pass”

Username = “robert”Password = “robert-pass”

Userstore

Bob has some difficult questions to find answers

“How am I going to migrate all our users into this central directory? I am sure there will be few teams who are not going to take this very well.”

“What type of user directory am I to propose for this centralized store? Engineering uses a JDBC database to store its users; IT uses an LDAP; which one should we go for in our centralized solution?”

“More importantly, does a user directory solve all the problem that I have now and may get in the future? I know that user directories can store identity attributes securely. But can they manage aspects such as uniqueness, temporality, ownership, trustworthiness of those attributes?”

“Can they store/track user behaviors”

“Can they manage identity relationships?”

“But the biggest of them all is that my user experience is still pretty bad. My users will have to enter the same set of credentials to get logged into each application they are going to use.”

“Is username/password authentication secure enough?”

Identity Integration

Brokered Authentication

Identity Broker(e.g. WSO2 IS)

Service provider(e.g. HR System)

Robert

Username = “robert”Password = “robert-pass”

Token

Token

Userstore

Standard authentication request

Single Sign On

Robert

Mail ClientUsername = “robert”Password = “robert-pass”

HR System

Expense Management

System

Username = “robert2”Password = “robert2-pass”Username = “robert”Password = “robert-pass”

Username = “robert”Password = “robert-pass”

Identity Broker(e.g. WSO2 IS)

Decouple Authentication and SSO

Bob realizes that what he wants is an Identity Provider that provides,

• Identity Integration• Brokered Authentication• Single Sign On• Decoupling of Authentication Method from SSO Protocol

Bob sets up an Identity Provider ...

OpenID Connect Complete Protocol Suite Support

“My authorization rules are all over my applications, and I am having a hard time managing them because,• They have been written into the applications’ code• They are constantly changing”

Bob faces another problem ...

How can I ...

• Effectively govern my resources• Globally enforce access control policies on those

resources• Make any policy updates immediately effective• Get a consolidated set of audit trails on who is

accessing those resources with all other contextual details

Defining Resource Access

• Subject– User– Group

• Object– Protected Resource

• Verb– Action that can be performed on a protected

resource• Context

– Environmental attributes such as time, Client IPs, etc.

Understanding Bob’s problem

Understanding Bob’s problem

Resources bring permissions to our Identity ecosystem

Permission = {Resource + Action}

There are only two kinds of authorization problems

in the world ...

Is Alice allowed to update accounts?

What resources is Alice allowed to update?

Bob searches for some existing authorization models

• Access Matrix / Access Control Table / Access Control List• Role Based Access Control (RBAC)• Group Based Access Control• Attribute Based Access Control (ABAC)• Ownership and sharing based Access Control• Multilevel Access Control

All of them seem to have some limitation

• The number of rules grow and become hard to manage• Not fine grained enough.• Hard to manage with a constantly changing environment.

Bob: “If only my authorization logic was centralized,

externalized, policy based, fine-grain and easy to

manage...”

eXtensible Access Control Markup Language (XACML)

/data/files

/data/archives

/data/visualize

/data/details

Policy decision Point

If user = jane Permit.

If role = clark andAction = writeDeny.

Policy Store

Policy Administration Point

Policy Enforcement Point(PEP)User = Tao

User = David

User = Jane

Trivia:

Authentication, authorization, and auditing are collectively

known as the gold standards of security. All three words start

with the prefix 'Au'; which is the periodic symbol for Gold.

Authentication, Authorization and Auditing are done

Bob: “Still I am provisioning all new accounts manually to our

Identity Broker as well as each and every cloud application

that we use. Although they support federated authentication

with our Identity Broker still they need a mapped account in

the cloud. If only I can automate that..”

Outbound Provisioning

Identity server

Extern Inc.

<<< Create User >>>Username: janeEmail: jane@extern.com

Cloud email service

<<< Create User >>>Username: janePassword: jane123Email: jane@extern.com

<<< Create User >>>Username: jane

<<< Create User >>>Username: jane@extern.com

Contacts DirectoryExpense Management System

Bob: “I would also like to be able to decentralize

control and empower my users to govern their

identities but with set of governance policies to

control it.”

Self Sign Up

Workflows

Identityserver

Update roles

Approve role assignment

Approve role assignment

Assigned to “supervisors” role

Assigned to “James”

Event Handler

Request Initiator

Callback Handler

Executor Manager

Database

Process Template

Initializer

Executor

Process Template Implementations

WSO2 IS Workflow Architecture

Account Recovery

• User onboarding

• Account Disabling

• Account Locking

• Brute Force Prevention

• Idle Account Locking

• Password Complexity policies

• Password History

• Password Expiry

• Admin Initiated Password Reset

• Account Linking

Identity Governance and Administration (IGA)

WSO2 IS Analytics

Analytics

Analytics

Analytics

• Login Attempts– By user

– By role

– By identity store

– By service provider

– By identity provider• Alerts

– Suspicious login

– Abnormally long sessions

• Sessions– Top longest durations

– Average session duration

per user

– Session count

Analytics

Alright Yeah!! Bob’s got a top notch Identity Management system

running in place that manages all his employee accounts efficiently.

Bob has been promoted as an Identity Architect in the company!!

The board has decided to acquire company “Y” across the globe. The

CTO tells Bob that those new employees will need to have access to

their applications and wants him to see how best they can manage

access from those other employees to the existing applications.

After some time ...

• “Y” has its own Identity and Access Management

system just like “X”.

• The system is connected to their corporate user

directory.

• The security architect over there will not expose the

corporate directory directly outside the firewall for

“X” to consume.

• Bob doesn’t want to be going and changing all their

applications to support this new Identity Provider.

Things are not looking good for Bob ...

Problem:

• Users will use applications across

enterprise borders and cloud

Solution:

• Multiple trust domains with

multiple Identity Providers

• Federated authentication based on

the trust relationship

Identity Federation

Bob goes into the meeting with Y’s security architect

thinking that this is a done deal. In the meeting he gets

to know that their Identity Provider doesn’t support

“OpenID Connect”. It only supports “SAML2 SSO”.

Bob: “All our applications here work with OpenID

Connect. What kind of Identity Provider doesn’t

support OpenID Connect.

Also I saw that they are using some custom claim URIs

that is not part of OpenID Connect.”

Bob has a meeting with Security Architect of “Y”

Federation Silos

Problem:

• Multiple Identity Federation protocols

• E.g. OpenID Connect, SAML2, OpenID, CAS, etc.

Identity Bus

1. Identity Hub

2. Identity Bridge

3. Claim Transformation

4. Role Transformation

Bob: “How am I going to authorize these users? Our authorization is

entirely centralized in our Identity Provider. Our applications talk

with our Identity Provider for authorization. Y’s IAM couldn’t even

do OpenID Connect. There is no way in the world it supports XACML.

And before I forget we also need to provision accounts for these

users in all our cloud applications.”

But wait ...

Just-In-Time (JIT) Provisioning

IdentityBroker

Identity Broker

Username: janePassword: jane123Email: saman@wso2.com

1. Access request

2 .Auth request

3. Auth request

4. Auth response

User Directory

5. Add user

Outbound JIT Provisioning

IdentityBroker

Identity Broker

Username: janePassword: jane123Email: saman@wso2.com

1. Access request

2 .Auth request

3. Auth request

4. Auth response5. Add user

Provisioning Bridge

“Phew!! That was close. I was saved by the Bus.”

Hop on to the Enterprise Identity Bus

Extending the Identity Ecosystem

Bob’s CTO calls him and tells him, “we have decided to expose our

internal applications as services for our clients to consume. Find out

how we can expose them securely”

Bob was expecting this to come his way, with all the hype

surrounding APIs.

Some time goes by and ....

Problem:

Consumers need access to backend APIs on behalf of the logged

in user.

Solution:

Delegated Access Control with OAuth2

First result on Google Search reveals OAuth2

Bob’s CTO again calls him and tells him, “we have decided to

consume one of our partner services through our API gateway.

However it is a secured endpoint which expects some kind of an

authorization token.”

Time goes by again ...

• Frequently, downstream services need to make data level

entitlements and need to record an identity in the audit trail.

• To do so, the service must know the identity of the end user.

Trusted Subsystems

• Trusted subsystem generated identity tokens

When downstream services trust the trusted subsystem to assert the

original caller's identity, without requiring additional evidence from other

parties. These tokens are self-issued and self-contained.

• Third party generated identity tokens

When the downstream services trust the trusted subsystem to assert

claims regarding the original caller in conjunction with third party evidence

that satisfies an additional set of security requirements. They can be

self-contained tokens.

Trusted Subsystems - Identity Flows

• User self-signed tokens

When the trusted subsystem is authorized to perform a set of application

functions and when there must be evidence from the original caller that the

caller initiated the request.

• Identity/Credential Mapping

Special function of the trusted subsystem role, where the goal is to

transform an identity to another related identity for the purpose of gaining

access to downstream resources that only recognize the transformed identity.

Trusted Subsystem - Identity Flows

Bob decides to use JWT Grant Profile for OAuth2

• Identity Provider

• Centralized Authorization and Auditing

• Outbound Provisioning

• Self service and Account and Password Control Policies

• Workflows

• Analytics

• Identity Federation

• Just-In-Time Provisioning / Provisioning Bridge

• Delegated Access Control

• Trusted Subsystems

Bob’s successful journey so far in the digital enterprise ...

Thank You!