Solutions for strong identity and access management (IAM), whether the user is a person or a device, will be critical to the success of a digital business. And because many digital apps and services now span several ecosystems, federated identity management will be important to ensure robust security without compromising usability and the customer’s experience. This session will explain the benefits of incorporating a comprehensive IAM solution in your digital transformation journey. It will discuss how IAM can Speed up automated provisioning and improve employee productivity Remove all barriers to entry with BYOID, enabling easy access anywhere Enhance user experience with single sign-on and unified identity Increase business agility with easy adoption of SaaS offerings Manage your identity in an API economy

1. End to End Identity Management
Johann Dilantha Nallathamby
Technical Lead
WSO2

2. Defining the Topic
1. Define Identity
2. Define end-to-end
3. Define Managing of Identities

3. Defining Identity
Simply,
• Who am I?
• What are my attributes?
• What are my behaviours?
• What are my relationships?

4. Defining End-to-End
Life of a single Identity over time

5. Defining End-to-End
Resource access by Identities at a given snapshot of time

6. Defining Management

7. Defining Management
I am an Engineer, not a manager!!
Let’s look at management in terms of challenges and solutions

8. 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

9. 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 :)

10. 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!!

11. User accounts in all the systems
Robert
(An employee)
Cloud email Service
Username = “robert”
Password = “robert-pass”
Expense
Management
System
HR System
Username = “robert2”
Password = “robert2-pass”
Username = “robert2”
Password = “robert2-pass”
Username = “robert_5”
Password = “K67robert2-AB-#2”

12. Bob thinks why not a centralized user directory?

13. 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”
User
store

14. 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?”

15. “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?”

16. “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.”

17. “Is username/password authentication secure enough?”

18. Identity Integration

19. Brokered Authentication
Identity Broker
(e.g. WSO2 IS)
Service provider
(e.g. HR System)
Robert
Username = “robert”
Password = “robert-pass”
Token
Token
User
store
Standard authentication request

20. 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)

21. Decouple Authentication and SSO

22. 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 ...

23. OpenID Connect Complete Protocol Suite Support

24. “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 ...

25. 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

26. 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

27. Understanding Bob’s problem
Resources bring permissions to our Identity ecosystem
Permission = {Resource + Action}

28. There are only two kinds of authorization problems
in the world ...
Is Alice allowed to update accounts?
What resources is Alice allowed to update?

29. 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

30. 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.

31. Bob: “If only my authorization logic was centralized,
externalized, policy based, fine-grain and easy to
manage...”

32. eXtensible Access Control Markup Language (XACML)
/data/files
/data/archives
/data/visualize
/data/details
Policy decision Point
If user = jane
Permit.
If role = clark and
Action = write
Deny.
Policy Store
Policy Administration
Point
Policy Enforcement
Point(PEP)
User = Tao
User = David
User = Jane

33. 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

34. 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..”

35. Outbound Provisioning
Identity server
Extern Inc.
<<< Create User >>>
Username: jane
Email: jane@extern.com
Cloud email service
<<< Create User >>>
Username: jane
Password: jane123
Email: jane@extern.com
<<< Create User >>>
Username: jane
<<< Create User >>>
Username: jane@extern.com
Contacts Directory
Expense Management
System

36. 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.”

37. Self Sign Up

38. Workflows
Identity
server
Update roles
Approve role
assignment
Approve role
assignment
Assigned to
“supervisors” role
Assigned to “James”

39. Event Handler
Request
Initiator
Callback
Handler
Executor Manager
Database
Process
Template
Initializer
Executor
Process Template Implementations
WSO2 IS Workflow Architecture

40. Account Recovery

41. • 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)

42. WSO2 IS Analytics

43. Analytics

44. Analytics

45. Analytics

46. • 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

47. 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!!

48. 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 ...

49. • “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 ...

50. 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

51. 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”

52. Federation Silos
Problem:
• Multiple Identity Federation protocols
• E.g. OpenID Connect, SAML2, OpenID, CAS, etc.

53. Identity Bus
1. Identity Hub
2. Identity Bridge
3. Claim Transformation
4. Role Transformation

54. 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 ...

55. Just-In-Time (JIT) Provisioning
Identity
Broker
Identity Broker
Username: jane
Password: jane123
Email:
saman@wso2.com
1. Access request
2 .Auth request
3. Auth
request
4. Auth
response
User
Directory
5. Add user

56. Outbound JIT Provisioning
Identity
Broker
Identity Broker
Username: jane
Password: jane123
Email:
saman@wso2.com
1. Access request
2 .Auth request
3. Auth
request
4. Auth
response
5. Add user

57. Provisioning Bridge

58. “Phew!! That was close. I was saved by the Bus.”
Hop on to the Enterprise Identity Bus

59. Extending the Identity Ecosystem

60. 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 ....

61. 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

62. 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 ...

63. • 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

64. • 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

65. • 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

66. Bob decides to use JWT Grant Profile for OAuth2

67. • 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 ...

68. Thank You!