eBay Identity Assertion Framework (IAF)

Identity Assertion Framework Framework for Distributed and Federated Authentication

What is the problem we are solving? A Multi-Mode, Policy Driven, Interoperable, Federated Security Token Service for Distributed Computing Environments Well, now that we clear that up …

Claims of Identity Farhang Kassaei eBay Platform & Application Architecture [email_address] Download @ http:// S oftware F or A ll S easons.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-In Or AuthN Registration Applications Applications Services Data Sources

A Typical Distributed System Back Office User Facing 3 rd Party Partners Event Listeners Batch Tools Data Sources Services Identity Directories

Forces of Distributed System: Security Check Points 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. - 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 DCE This 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. - 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 - 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? Whose data you want to access Self Asserted Asserted by an Authority Own Someone else’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* - 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. - 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/STS Policy Store Service Providers Consumers Users Identity Directories Assertion Providers Guards

IAF System Architecture

IAF Internal Architecture STS Policy Services Interface Session Provider Internal Bus Listener A Listener B Listeners IAF Service Interface P luggable A uthentication M odules Key Provider Federation & Domain Mgmt P luggable A ssertion P roviders Codecs Delegated Auth Router Assertion Cache

Protocol

Binding and Profile Bindings - HTTP - Web (both direct and delegated) - SOAP Profiles - Mobile (native) - Desktop - Set Top (in progress)

Token Format - SAML Artifact - XML - SAML 2.0 Encoding - 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 Service Policy Service 1 2 3 4 5

Agent/Delegated Access Protocol A 11 10 7 8 6 5 9 4 9 4 Consumer SP IAF Service Policy Service 1 IDP Service IDP Login App/Flow Consumer Client 2 3 12 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 Domain Protection Token Policies Service Provider Identity Directories IAF Instance Policy Service 1 1 N 1 N 1 0..N 1..N N 1

The System Model

Example of Security Domains

Policy Key and Policy Resolution IAF (Issue) Guard (validate) Determining Security Domain from a Request If (req.secDomain) return req.secDomain Else 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/use SD SP IDP Policy Doc

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

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.

http://softwareforallseasons.blogspot.com	154
http://softwareforallseasons.blogspot.de	7
http://www.slideshare.net	5
http://softwareforallseasons.blogspot.in	3
http://softwareforallseasons.blogspot.ch	2
http://softwareforallseasons.blogspot.com.au	1
http://softwareforallseasons.blogspot.ro	1

eBay Identity Assertion Framework (IAF)

by Farhang Kassaei

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 173

Statistics