View
5.899
Download
0
Category
Preview:
DESCRIPTION
Abstract: Identity, authentication and authorization are the glues for modern, distributed applications, they affect security, availability and usability directly and could also be a significant barrier to adoption of distributed paradigms such as SOA and Cloud. Performing these tasks in monolithic systems are fairly well understood, but distributed environments of applications and services with heterogeneous security profiles often present different challenges. In this talk we present architectural models, deployment techniques and policy management ideas representing the top 10 most important lessons we learned from implementing large scale distributed authentication scheme for eBay marketplaces, PayPal and eBay Mobile.
Citation preview
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 …
- 3 - eBay, Inc. Proprietary
Claims of Identity
Farhang KassaeieBay Platform & Application Architecture
fkassaei@ebay.com
Farhang KassaeieBay Platform & Application Architecture
fkassaei@ebay.com
Download @Download @
http://SoftwareForAllSeasons.blogspot.com/
- 4 - eBay, Inc. Proprietary
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
- 5 - eBay, Inc. Proprietary
Audience Profiling – Show of hands
- SAML
- OAuth
- OpenID
- Kerberos
- Distributed Systems (SOA, WOA, REST etc.)
- WS-SecurityPolicy
- Access Control (ACL, RBC, XACML etc.)
- 6 - eBay, Inc. Proprietary
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.
- 7 - eBay, Inc. Proprietary
A Typical Monolithic Systems
Sign-InOr AuthN
Registration
ApplicationsApplications
Services
Data Sources
- 8 - eBay, Inc. Proprietary
A Typical Distributed System
BackOffice
UserFacing
3rd Party
Partners
EventListeners
Batch
Tools
Data Sources
Services
IdentityDirectories
- 9 - eBay, Inc. Proprietary
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
- 10 - eBay, Inc. Proprietary
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
- 11 - eBay, Inc. Proprietary
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
- 12 - eBay, Inc. Proprietary
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
- 13 - eBay, Inc. Proprietary
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
- 14 - eBay, Inc. Proprietary
Forces of Distributed System: Multiple Access Models
- Direct Access Model
- Delegated/Agent Access Model- Impersonation Access Model
- 15 - eBay, Inc. Proprietary
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
- 16 - eBay, Inc. Proprietary
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!
- 17 - eBay, Inc. Proprietary
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.
- 18 - eBay, Inc. Proprietary
IAF System Architecture
IAF/STSIAF/STS
Policy Store
Service Providers
ConsumersConsumers
UsersUsers
Identity DirectoriesIdentity Directories
Assertion
Providers
Assertion
Providers
Guards
- 19 - eBay, Inc. Proprietary
IAF System Architecture
- 20 - eBay, Inc. Proprietary
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
- 21 - eBay, Inc. Proprietary
Protocol
- 22 - eBay, Inc. Proprietary
Binding and Profile
BindingsBindings
- HTTP
- Web (both direct and delegated)
- SOAP
ProfilesProfiles
- Mobile (native)
- Desktop
- Set Top (in progress)
- 23 - eBay, Inc. Proprietary
Token
FormatFormat
- SAML Artifact
- XML
- SAML 2.0
EncodingEncoding
- JSON
- GPB (Google Protocol Buffer)
- Pluggable Codec to support other encoding
- 24 - eBay, Inc. Proprietary
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
- 25 - eBay, Inc. Proprietary
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
- 26 - eBay, Inc. Proprietary
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.
- 27 - eBay, Inc. Proprietary
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
- 28 - eBay, Inc. Proprietary
The System Model
- 29 - eBay, Inc. Proprietary
Example of Security Domains
- 30 - eBay, Inc. Proprietary
Example of Security Domains
- 31 - eBay, Inc. Proprietary
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
- 32 - eBay, Inc. Proprietary
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
- 34 - eBay, Inc. Proprietary
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
- 35 - eBay, Inc. Proprietary
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
- 36 - eBay, Inc. Proprietary
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).
- 37 - eBay, Inc. Proprietary
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.
Recommended