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

1. Patterns and Antipatterns in
Enterprise Security
Johann Nallathamby Malithi Edirisinghe
1

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

3. 1. Identity Integration / Virtual Directory
3

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

5. 2. Identity Broker
5

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

8. 3. Identity Federation
8

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

11. 3.1. Identity Federation Variation -1
Inter-Domain Token Exchange
11

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

14. 3.2. Identity Federation Variation -2
Intra-Domain Token Exchange
14

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

17. 3.3. Identity Federation Variation -3
Third Party Trust Establisher
17

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

20. 4. Identity Hub
20

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

22. Solution
One Identity Broker trusted by relying parties and federated parties
acting as a hub
22

23. 5. Identity Bridge
23

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

25. Solution
● Bridge between protocols.
SAML with OpenID Connect
25

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

27. 6. Claim/Role Transformer
27

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

29. 7. Multi-factor Authentication
29

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

31. 8. Multi-option Authentication
31

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

33. 9. Adaptive Authentication
33

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

35. 10. Authorization Patterns
35

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

38. 38
Access Control Patterns

41. 11. SSO with Delegated Access Control
41

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)

43. 43

44. 44

45. 12. Outbound Provisioning
45

46. 46

47. 47

48. 48

49. 49

50. 13. JIT Provisioning / Shadow Accounts
50

51. Requirements
● Transient Name IDs
● Persistent Name IDs
● Identity Protection
● Identity Mapping
● Identity Collision
51

52. 14. Trusted Subsystem
52

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.

58. 15. Security Gateway
58

59. 59

60. 60

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.

67. 67
Q & A