To view recording of this webinar please use below URL:
Attacks against information systems is on the rise making enterprise security a major concern. It’s important to identify and address security needs such as confidentiality, integrity, availability and auditability of information. Enterprise security patterns facilitate balanced and informed decisions about security needs, as well as provide a rationale for the evolution of security needs over time. Antipatterns, which are fostered by misapplications of concepts and misunderstandings of security concerns, should be avoided. Enterprise security patterns and antipatterns solve these security concerns by addressing recurrent problems and challenges. These security patterns facilitate balanced and informed decisions about security needs, avoid the misapplication of concepts and misunderstanding of security concerns and provide a rationale for evolution of security needs over time.
This webinar will
Deep dive into enterprise security patterns and antipatterns
Explore the importance of using them
Discuss how to apply them with WSO2 Identity Server
2. For whom?
● Looking to learn about Identity and Access Management Patterns to
solve real world business problems.
● Some experience with Identity and Access Management
Technologies. E.g. Directories, SAML2, OAuth2 which are some of the
most commonly used data standards / protocols for transporting
Identity and Access Management data.
● Main focus is on Identity and Access Management Patterns.
○ NOT Network Security
○ NOT OS Security
2
4. Problem
● Users to the system can come from multiple sources
● A single user’s attributes can come from multiple sources
● User credentials and attributes can come from separate sources
Solution
● Mount multiple user stores for
user management and make the
number and type of user stores
transparent to the application
● Connect the credential stores and
identity stores to the system and
provide a unified view of the
user's’ identity hiding away the
complexity in aggregating those
data
4
6. Problem
Users will work with multiple applications in an enterprise.
They will have to use specific credentials for each.
● Disjointed User Experience
● Complicated user and account management
● Security Threats
Solution
Delegate authentication to a trusted
identity provider - Brokered Identity
6
7. Benefits
● Single Sign On
● Separate user authentication from application code
● Hides user credentials from applications
● Removes administrative overhead from applications
● Improves user experience
Limitations
● Authentication can be a single point of failure.
● Introduce a single point where the security of the entire system can
be breached
7
9. 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
9
10. Benefits
● Single Sign On
● No need of managing accounts in the on premise userstore
● Reduce administration overhead
Limitations
Security of the system can be compromised if any of the Identity Provider
that your Identity Provider trusts are breached.
10
12. Problem
A consumer who is living in a trust domain needs to interact with a
service that is developed in a federated trust domain
Solution
Establish a trust relationship between the two Identity Providers residing
in each trust domain.
IdP-A IdP-B
Consumer Service
Trust
Trust
Trust
Trust Domain A Trust Domain B
12
13. Benefits
● Flexible in maintaining trust domains
● Facilitates federated interactions between consumers and services
across trust domains
● Same model can be extended to address more complex federation
scenarios
Limitations
Introduces certain level of dependency between the consumer and the
Identity Provider in the other trust domain
13
15. Problem
A consumer who is living in a trust domain needs to interact with a
service that is developed in a federated trust domain, without any
dependencies to entities in the other trust domain
Solution
Consumer presents the token to the service in the other trust domain.
Service will validate the token with its Identity Provider.
IdP-A IdP-B
Consumer Service
Trust
Trust
Trust
Trust Domain A Trust Domain B
15
16. Benefits
● Removes dependencies between consumers and service in different
trust domains
● Can handle different token claim representations
Limitations
● Adds complexity to the mechanism used to model the trust
relationship with the Identity Provider in the other trust domain
● Makes the services to accept messages that are not issued by the
Identity Provider that they trusts
16
18. Problem
Creation of trust between Identity Providers can be complex.
Ex:
Cannot establish direct trust relationship as some identity information
cannot be shared with partner company.
Solution
Establish the trust
relationship with a
third party Identity
Provider, that act as a
bridge between other
Identity Providers
IdP-A IdP-B
Consumer Service
Trust
Trust
Trust
Trust Domain A
Trust Domain BIdP-C
Trust Trust
18
19. Benefits
Isolates the complexities of the federated environment from different
trust domains
Limitations
Introduces a new component that needs to maintained
19
21. Problem
● Increasing no of Service Providers and Identity Providers
● Each Service Provider has to trust Each Identity Provider
Not scalable
Hard to manage
Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2.
html
Spaghetti
21
24. Problem
● Multiple Identity Federation Protocols
SAML, OpenID Connect, WS-Federation etc.
● But federation systems relies on only one protocol
Ex:
Silo of SAML Federation
Silo of OpenID Connect Federation
Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2.
html
Federation
Silos
24
26. Benefits
● Single Sign On across heterogeneous protocols
● Identity federation between Service Providers and Identity Providers
with heterogeneous federation protocols
● Scalability
Limitations
● Authentication can be a single point of failure.
● Introduce a single point where the security of the entire system can
be breached
26
28. Problem
Service Providers may not be able to understand claims or roles of the
subject, in the format issued by Identity Providers and vise versa.
Solution
Convert incoming claims to the expected format
Benefits
● Process claims in a single point reducing the complexity of enforcing
brokered trust
● Can be used with legacy systems
28
30. Problem
Digital identity fraud is still on the rise
Needs “strong” user authentication
Solution
Use two or more authentication factors
● Something known to only the user (Knowledge based)
password, shared secret, PIN
● Something held only by the user (Possession based)
security token, smart card, mobile device
● Something inherent only to the user (Biometric)
facial recognition, fingerprint, voice recognition
30
32. Problem
Multiple domains essentially isolated due to lack of mutual inbound or
outbound trust relationships.
Service Providers opt for different login options
Solution
Multiple login options are presented to the user as per the Service
Provider application.
32
34. Problem
Needs “strong” user authentication, if and only if there is an actual risk.
Solution
Provide additional authentication steps, if and only if the risk profile
(derived from a matrix of variables) is high.
Enhance user experience
34
36. 36
MAC vs. DAC
● Mandatory Access Control (MAC)
○ Centralized security policy
○ Users do not have the ability to override the policy
● Discretionary Access Control (DAC)
○ Governs the ability of subjects to access objects
○ Allows users the ability to make policy decisions and/or assign
security attributes.
○ The traditional Unix system of users, groups, and read-write-
execute permissions is an example of DAC.
37. 37
Access Control Patterns
● Access Matrix / Access Control Table / Access Control List
● Role Based Access Control (RBAC)
● Group Based Access Control
● Claim Based Access Control
● Policy Based
● Hierarchical Authorization
○ Hierarchical Tenants
○ Hierarchical Groups/Roles
○ Hierarchical Resources
● Multilevel Access Control
42. Problem
Consumers need to access back-end APIs on behalf of the logged in user.
42
Solution
Should adhere to some access delegation protocol
Ex: OAuth
Exchange the authentication token to some access token
SAML token, JSON Web Token (JWT)
53. 53
Problem
Securing a n-tier application
● Securing only the top most layer
● Expansion in the number and kinds of users
● Heterogeneous devices
● Unlimited connections
● Who should be allowed to access the data?
● Cannot protect from an attack originating from the local area
network within the company.
● Who has already accessed the data?
Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-w
html
54. 54
Solution 1
Impersonation and Delegation
● Delegation is the process of allowing another party to act on behalf
of an identity.
● This process bestows upon a party the rights and privileges of
another party to perform a set of tasks.
● Impersonation can be viewed as the most relaxed form of
delegation, such that one identity is assigned the complete set of
permissions of the impersonated identity.
55. 55
Solution 2
Trusted Subsystem
● Trusted subsystem model implies that application services are trusted
to perform a specific set of application tasks.
● Frequently, downstream services need to make application
authorization decisions.
● To do so, the service must know the identity of the end user.
● While the ability to flow the identity of the end user is an inherent
property of the delegation model, it is not so for the trusted subsystem
model and special efforts must be made to include this feature.
Source : https://msdn.microsoft.com/en-us/library/aa905320.
aspx#trstsubsysdes_topic6
56. 56
Solution 2 Contd.
Trusted Subsystem
● Authenticate and verify the identity of the upstream or downstream
service they are communicating with.
● Decide if the identified service is a trusted subsystem for a specific set
of application functions, including propagating identity claims.
● Protect the integrity of the data being communicated between trusted
subsystem and downstream services. Besides application data and
application plumbing data, such as the identity claims of the original
user, must also be protected so that no man-in-the-middle can modify
the identity information that is in transit.
57. 57
Solution 2 Contd.
Trusted Subsystem - Identity Flows
● Trusted subsystem generated identity tokens / Self-issued
○ When downstream services trust the trusted subsystem to assert the
original caller's identity, without requiring additional evidence from
other parties.
● Third party generated identity tokens / Self-contained
○ 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.
● 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.
61. 61
Audit Interceptor
Requirement
● Log security incidents to trace system abuse:
○ Failed login attempts
○ Unauthorized access attempts to services
Solution
● All messages flow through the a gateway of the system.
● Necessary auditing is done by the logging at the gateway.
62. 62
Data Origin Authentication
Requirement
● Non-repudiation
Solution
● Digital Signature
Data Confidentiality
Requirement
Protect sensitive personal data during transmission from:
● Tampering
● unauthorized access
Solution
● Digital Encryption
63. 63
Message Screening
Requirement
Mitigate damages to the system from messages with malicious content
● SQL injection
● X-Doc attacks
Solution
● XML Schema validation.
● Regular expression validation to avoid SQL injections contained in
strings.
● An application of Perimeter Security
64. 64
Replay Mitigation/DoS Safety
Requirement
Prevent denial of service attacks caused by replaying valid messages.
Solution
● Apply throttling rules at the entry point.
● Validate message freshness by WS-Security mechanisms
(Timestamp/Nonce).
● An application of Perimeter Security.
65. 65
Exception Shielding
Requirement
Avoid exposing sensitive data through exceptions.
● Legacy application code might throw exceptions containing sensitive
information.
● Need to filter those exceptions when system is exposed to external
parties.
Solution
● Sanitize unsafe exception data by replacing it with non-harmful
exception message and give the right level of detail to the user.
66. 66
References
[1] https://msdn.microsoft.com/en-us/library/
[2] http://soapatterns.org/
[3] https://medium.facilelogin.com/thirty-solution-patterns-with-the-wso2-identity-server-
16f9fd0c0389#.1f3slrjnt
[4] http://wso2.com/library/blog-post/2014/10/blog-post-identity-anti-patterns-federation-silos-
and-spaghetti-identity/
[5] http://wso2.com/library/webinars/identity-server/
[6] M. Schumacher, E. Fernandez-Buglioni and D. Hybertson, Security Patterns: Integrating
Security and Systems Engineering. 2005.