ebay identity assertion framework (iaf)

TM

eBay, Inc. Proprietary

Identity Assertion FrameworkFramework for Distributed and Federated Authentication

- 2 - eBay, Inc. Proprietary

What is the problem we are solving?

A Multi-Mode, Policy Driven, Interoperable, Federated Security

Token Service for Distributed Computing Environments

A Multi-Mode, Policy Driven, Interoperable, Federated Security

Token Service for Distributed Computing Environments

Well, now that we clear that up …Well, now that we clear that up …


Claims of Identity

Farhang KassaeieBay Platform & Application Architecture

[email protected]

Farhang KassaeieBay Platform & Application Architecture

[email protected]

Download @Download @

http://SoftwareForAllSeasons.blogspot.com/


What is to Come

- Distributed systems forces & impact on authentication

- IAF Architecture (that is the multi-mode, policy driven, interoperable …thing)

- The Top 10 Lessons We Learned

- Token, Protocol, Binding and Profiles

- Policy, Security Domains and Federation

- Little note: Are we talking about OAuth or OpenID here?

- System Models


Audience Profiling – Show of hands

- SAML

- OAuth

- OpenID

- Kerberos

- Distributed Systems (SOA, WOA, REST etc.)

- WS-SecurityPolicy

- Access Control (ACL, RBC, XACML etc.)


Are we talking about OAuth or OpenID?

- This is about the systems that issues OAuth tokens (OAuth Provider) or providers of other tokens.

- Not Really OpenID

- Discuss Delegated/Agent Authentication & OAuth, but it is not the main focus.


A Typical Monolithic Systems

Sign-InOr AuthN

Registration

ApplicationsApplications

Services

Data Sources


A Typical Distributed System

BackOffice

UserFacing

3rd Party

Partners

EventListeners

Batch

Tools

Data Sources

Services

IdentityDirectories


Forces of Distributed System: Security Check Points

More components has to perform authentication – more guards

More components has to perform authentication – more guards

- Fewer security boundaries in monolithic systems

- Mostly operates in trusted mode.

- Lot more security boundaries in distributed systems

- Crossing most boundaries requires authentication.

- Fewer Nouns (Subject and Objects) in monolithic systems


Forces of Distributed System: Identity vs. Authentication

SPs do not need to perform primary authentication, they just need to know that a consumer has been authenticated by a

trusted party.

SPs do not need to perform primary authentication, they just need to know that a consumer has been authenticated by a

trusted party.

- SP does not and should not access Consumer’s primary credentials

- What would SP do with primary credentials?

- Has to understand where identity directory is.

- Has to understand primary auth mechanisms

- Has to make changes as primary auth mechanism change


Forces of Distributed System: Multiple Assertion Providers

Fact of life in DCEThis data is normally needed for authorization

Fact of life in DCEThis data is normally needed for authorization

- Profile data normally variety of data sources

- User Segments perhaps in marketing DB

- Roles and Groups

- State Variables (life cycle etc.) in main directory

- Exceptions (White list, black list memberships)

- Subject/User information are in different data sources

- Different access patterns, latencies, cache-ablity, even availability characteristics


Forces of Distributed System: Multiple Identity Repo

Each is likely to have its own identity directory.No way to consolidate all directories into one. Each is likely to have its own identity directory.No way to consolidate all directories into one.

- End Users

- Internal Applications

- Services/Services Providers

- Third Party Apps/Consumers

- Customer Support

- Other internal constituencies

- Batch Applications and Tasks

- Tools (rollout, build etc.)

- Partners and Suppliers


Forces of Distributed System: Heterogeneous Policies

Different SPs inevitably will require different policies for the token they accept

Different SPs inevitably will require different policies for the token they accept

- Encryption related

- Integrity and Signature Related

- Order of Operations- Required Assertions

- Key Managements Policies

- Scope Policies - Session and Freshness Policies

- Chain of Custody

- Required Headers

- Value Semantics (Pure Value, Reference)

- Others


Forces of Distributed System: Multiple Access Models

- Direct Access Model

- Delegated/Agent Access Model- Impersonation Access Model


Authentication Scenarios

How does consumer establish Identity?How does consumer establish Identity?

Who

se d

ata

you

wan

t to

acc

ess

Who

se d

ata

you

wan

t to

acc

ess

Self Asserted Asserted by an Authority

Ow

nS

omeo

ne e

lse’

s

Trusted Apps or apps that carry only identifier and time stamp

Shared Secret & Sign

Admin/Tools/Internal Apps/ Apps “UNP”

mode

Shared Secret & Sign

Token and Claims

Token and Claims

Apps that carry consequential claims/assertions

Agent Applications Requires Consent

Does not Require Consent


Forces of Distributed System: Consumer Simplicity

System should not look distributed to consumers*System should not look distributed to consumers*

- Consumers do not want to know about all of the forces we talked about so far !

- Easy Access Models: Give me a token that allows me to consume services I need. Do not ask me (or my users) to authenticate ever single time.

- Requires some form of federation: If I can access a higher security service, I should be able to access a lower security service as well.

- Support direct, delegated and impersonated

* To the extent possible, limits apply!


Forces of Virtualization: Statelessness

Tough to use elastic capacity if compute/boxes are special purpose.

Tough to use elastic capacity if compute/boxes are special purpose.

- Security Requirements and grouping/mapping of Consumers and Services should be abstracted in logical form, not implemented in physical topology and wiring.

- The “compute” or the infrastructure should be stateless.

- Not only loosely coupled to your consumers but loosely coupled to your infrastructure.


IAF System Architecture

IAF/STSIAF/STS

Policy Store

Service Providers

ConsumersConsumers

UsersUsers

Identity DirectoriesIdentity Directories

Assertion

Providers

Assertion

Providers

Guards


IAF System Architecture


STS

IAF Internal Architecture

PolicyServicesInterface

SessionProvider

Internal Bus

Listener AListener B

Listeners

IAF

Ser

vice

Int

erfa

ce

PluggableAuthenticationModules

Key Provider

Federation &Domain Mgmt

PluggableAssertionProviders

Codecs Delegated Auth Router

Assertion Cache


Protocol


Binding and Profile

BindingsBindings

- HTTP

- Web (both direct and delegated)

- SOAP

ProfilesProfiles

- Mobile (native)

- Desktop

- Set Top (in progress)


Token

FormatFormat

- SAML Artifact

- XML

- SAML 2.0

EncodingEncoding

- JSON

- GPB (Google Protocol Buffer)

- Pluggable Codec to support other encoding


Direct Access Protocol

RequestSecurityToken (Id, IDP, [SP], [SD])

coarse authorization (U, SP)

getSecurityDomain (U, IDP, SP)

getPolicy (SD, SP)

mintToken(U, Policy)

getAssertions(U, Policy)

return packageToken(Token)

Login (Id@pIDP, Secret)

CallServiceProvider(Token)

Consumer

SP

IAF ServiceIAF Service

Policy ServicePolicy

Service

11

22

33

44

55


AA1111

1010

77

88

665599

44

99

44

Agent/Delegated Access Protocol

Consumer

SP

IAF ServiceIAF Service

Policy ServicePolicy

Service

11 IDP ServiceIDP Service

IDP Login App/FlowIDP Login App/Flow

Consumer Client

Consumer Client

22

33

1212

RequestSecurityToken (ConsumerId, U, SP)

coarse authorization (U, SP)

getRequestToken (ConsumerId, U, SP)

Login (Id, IDP, Secret)

CallServiceProvider(Token)

RequestAuthorizedToken (ConsumerId, U, SP)

RequestAccessToken (requestToken)

RequestRequestToken (ConsumerId, [U, SP]) – via double redirect


Policy, Security Domain, Federation

- Groups of SPs normally conform/agree to the same set of policies

- Typically SPs impose policies/requirements on how tokens are issued and used. (see heterogynous policy slide)

- Often alignments exists between/among groups of SPs and Identity Repositories

- A logical grouping of SPs that are governed by the same set of policies is called a Security Domain.


Security Domain Definition

Security DomainSecurity Domain

Protection Token Policies

Protection Token Policies

Service ProviderService Provider Identity DirectoriesIdentity Directories

IAF Instance

IAF Instance

Policy ServicePolicy Service

1

1

N

1

N

1

0..N1..N

N 1


The System Model


Example of Security Domains


Policy Key and Policy Resolution

IAF(Issue)

IAF(Issue)

Guard(validate)

Guard(validate)

SD SP IDP Policy Doc

Determining Security Domain from a RequestDetermining Security Domain from a Request

If (req.secDomain) return req.secDomainElse if (Policy.SEC_DOMAIN_PER_USER_OR_ROLE) if (getSecurityDomainFor(req.subject) != NULL return getSecurityDomainFor(req.subject)Else if (req.sp) return getSecurityDomainFor(sp)Else if (req.IDP) return getSecurityDomainFor(IDP)Return Error

Determining Policy to apply/useDetermining Policy to apply/use


Finally … The top 10 Lessons [we think] we learned

10- Shield SPs from performing primary authentication

9- Identity != Identifier, SPs almost always need more than identifier.

8- Chain of custody matters, who says it is as important as what is said.

7- Consider all consumers: Web, Mobile, Desktop, Set top, Tablets etc.

6- Think simple: Token, Protocol, Binding, Profile

5- Allow for operator controlled policies, let them trade security and performance

4- Separate logical security domains from physical topology

3- Define/Design Security Domains to gain maximum isolation

2- Design a well-articulated federation scheme, you will need it.

1- Take control: Do not let authentication schemes and policies proliferate.

-Tokens, Protocols, Bindings, Policies, Profiles

TM

eBay, Inc. Proprietary

Backup Slides


What are the different policies?

- Encryption related

- Integrity and Signature Related

- Order of Operations

- Required Assertions

- Key Managements Policies

- Scope Policies

- Session and Freshness Policies

- Chain of Custody

- Required Headers

- Value Semantics (Pure Value, Reference)

- Many others


A Few Keys to a Flexible Authentication Architecture

- Identity vs. Authentication

- Primary Authentication vs. Token Authentication

- Direct Access vs. Delegated Access

- Claim vs. Proof of identity

- Federal vs. Central

- Policy vs. Mandate

- Trust vs. Verification

Understand & treat these aspects correctly


Is This not an Authorization Issue?

- Partially it is about authorization and partially is about trust.

- The IAF service issues token for a certain security domain, effectively authorizing a subject to access a set of SPs (and not others), this is about (coarse grain) authorization.

- The other part is about trust. IAF tokens carry assertions that will be used as input by SP’s local authorization policies and therefore must be trusted assertions.

- Also remember that a good authorization schema always implemented in tiers/layers. IAF performs coarse grain authorization (who has access to what security domains), SPs performs finer grain authorization (what particular operations can a given subject perform).


What is a Security Boundary?

- A boundary that a subject must authenticate to cross

- Equivalently, callers must be authenticated (or at least identified) before their request is processed.

- Security boundaries are protected by guards that perform (or delegate performing of) authentication.

- When a Java objects invoke another Java objects, there is no security boundaries, the relationship is said to be trusted.

-A services (such as eBay API) forms a security boundary

- Often (but not always) security boundaries are out of process wrt. caller processes.

ebay identity assertion framework (iaf)

Technology