wso2con usa 2017: introduction to security: end-to-end identity management
TRANSCRIPT
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: [email protected]
Cloud email service
<<< Create User >>>Username: janePassword: jane123Email: [email protected]
<<< Create User >>>Username: jane
<<< Create User >>>Username: [email protected]
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: [email protected]
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: [email protected]
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!