Patterns and Antipatterns in Enterprise Security

Johann Nallathamby Malithi Edirisinghe

1

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

1. Identity Integration / Virtual Directory

3

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

2. Identity Broker

5

ProblemUsers 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

SolutionDelegate authentication to a trusted identity provider - Brokered Identity

6

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

3. Identity Federation

8

ProblemUsers will use applications across enterprise borders and cloud.

SolutionMultiple trust domains with multiple Identity Providers.Federated authentication based on the trust relationship

9

Benefits● Single Sign On● No need of managing accounts in the on premise userstore● Reduce administration overhead

LimitationsSecurity of the system can be compromised if any of the Identity Provider that your Identity Provider trusts are breached.

10

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

11

ProblemA consumer who is living in a trust domain needs to interact with a service that is developed in a federated trust domain

SolutionEstablish 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

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

LimitationsIntroduces certain level of dependency between the consumer and the Identity Provider in the other trust domain

13

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

14

ProblemA 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

SolutionConsumer 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

TrustTrust

Trust

Trust Domain A Trust Domain B

15

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

3.3. Identity Federation Variation -3 Third Party Trust Establisher

17

ProblemCreation of trust between Identity Providers can be complex. Ex: Cannot establish direct trust relationship as some identity information cannot be shared with partner company.

SolutionEstablish 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 ATrust Domain BIdP-C

Trust Trust

18

BenefitsIsolates the complexities of the federated environment from different trust domains

LimitationsIntroduces a new component that needs to maintained

19

4. Identity Hub

20

Problem● Increasing no of Service Providers and Identity Providers

● Each Service Provider has to trust Each Identity Provider Not scalableHard to manage

Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2.html

Spaghetti

21

SolutionOne Identity Broker trusted by relying parties and federated parties acting as a hub

22

5. Identity Bridge

23

Problem● Multiple Identity Federation Protocols

SAML, OpenID Connect, WS-Federation etc.

● But federation systems relies on only one protocol Ex:

Silo of SAML FederationSilo of OpenID Connect Federation

Source : http://blog.facilelogin.com/2014/10/identity-federation-patterns-with-wso2.html

Federation Silos

24

Solution● Bridge between protocols.

SAML with OpenID Connect

25

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

6. Claim/Role Transformer

27

ProblemService Providers may not be able to understand claims or roles of the subject, in the format issued by Identity Providers and vise versa.

SolutionConvert 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

7. Multi-factor Authentication

29

ProblemDigital identity fraud is still on the riseNeeds “strong” user authentication

SolutionUse 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

8. Multi-option Authentication

31

ProblemMultiple domains essentially isolated due to lack of mutual inbound or outbound trust relationships.Service Providers opt for different login options

SolutionMultiple login options are presented to the user as per the Service Provider application.

32

9. Adaptive Authentication

33

ProblemNeeds “strong” user authentication, if and only if there is an actual risk.

SolutionProvide additional authentication steps, if and only if the risk profile (derived from a matrix of variables) is high.Enhance user experience

34

10. Authorization Patterns

35

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

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

Access Control Patterns

11. SSO with Delegated Access Control

41

ProblemConsumers need to access back-end APIs on behalf of the logged in user.

42

SolutionShould adhere to some access delegation protocolEx: OAuth

Exchange the authentication token to some access tokenSAML token, JSON Web Token (JWT)

43

44

12. Outbound Provisioning

45

46

47

48

49

13. JIT Provisioning / Shadow Accounts

50

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

51

14. Trusted Subsystem

52

53

ProblemSecuring 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-wso2.html

54

Solution 1Impersonation 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

Solution 2Trusted 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

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

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.

15. Security Gateway

58

59

60

61

Audit InterceptorRequirement● 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

Data Origin AuthenticationRequirement● Non-repudiation

Solution● Digital Signature

Data ConfidentialityRequirementProtect sensitive personal data during transmission from:● Tampering● unauthorized access

Solution● Digital Encryption

63

Message ScreeningRequirementMitigate 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

Replay Mitigation/DoS SafetyRequirementPrevent 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

Exception Shielding

RequirementAvoid 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

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

Q & A