• Like
  • Save
Identity and Access Management in Service Oriented Architectures
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Identity and Access Management in Service Oriented Architectures

  • 1,811 views
Published

Identity and access management represent a cross-cutting concern in IT-systems that is en-abling security services such as authentication, SSO, and authorization. …

Identity and access management represent a cross-cutting concern in IT-systems that is en-abling security services such as authentication, SSO, and authorization.
This contribution will analyze the applicability of recent technology innovations for service-oriented architectures. An emphasis will be laid on identity federation.
Based on this analysis, the presentation will investigate the security architecture of a frame-work for component-based, service-oriented real-time communication services currently be-ing built at Siemens Communications.

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,811
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Identity and Access Management in Service-Oriented Architectures Dieter Hemkemeyer and Oliver Pfaff
  • 2. Agenda
    • Setting the scene
      • What is the need to manage identity and access in SOA?
    • Technology scouting
      • To deploy traditional or emerging identity and access management technologies?
    • Security architecture of the SOA framework
      • Which technology selection and composition?
    • Conclusions
  • 3. Setting the Scene Rationale of the SOA Framework at Siemens Com Today: Application 1 Application 2 Application 3 … Applications Tomorrow: Application 1 Application 2 Application 3 SOA framework … Applications Framework Cross-cutting concerns
  • 4. Setting the Scene Service Invocation Scenario SOA framework SOA framework Message Caller (e.g. Web-tier) Users Business service Resource beSecret Method doMagic Method doMagic Business delegate
  • 5. Setting the Scene The Need for IAM ( Identity and Access Management )
    • Without security measures: anybody may do anything in every service (by simply calling the business delegates of services)
      • A classical feature such as voice-mail already proves that this is inadequate ( everybody may talk to a voice-box but only “self” may listen the contents)
    • This mandates authorization on the granularity of service invocations (e.g. doMagic ) and operations on application objects (e.g. beSecret )
      • Authorization is delivered by access management
    • This requires authentication of service callers
      • Authentication requires the supply, maintenance and use of entity identifiers and authentication credentials, i.e. identity management
  • 6. Setting the Scene Sample Use Cases
    • Needs to be authenticated (to use the services and resources of the SOA system)
    • Simultaneously logon to all services of a SOA system
    • Transparently sign-on as Windows user
    • Needs to be administrator to update service bundle
    • Needs to be “self” to change buddylist
    • Needs to be entitled by the owner to obtain presence data
  • 7. Setting the Scene The Need for Identity Federation
    • Identity isn’t about the individual – it’s about relationship.
    Persistence tier Business logic tier Web tier ID-1 steeleagle.com ‚ Flight tickets‘
      • Exchange identity information with external providers
        • Identity isolation prohibits integration
    • How to organize identity to facilitate integration between autonomous services?
    ID-2 sweetdreams.com ‚ Hotel booking‘
      • Support separately managed identity stores
        • Autonomy requires separately managed identity stores. This prohibits direct synchronization.
      • Exchange identity information in a secured and interoperable way between Web and business logic tier systems.
        • That’s the idea of identity federation ...
  • 8. Setting the Scene Identity Federation
    • Allows organizations to consume identities issued by other organizations:
      • Identity provider:
        • The issuer of the identity - acting as an authentication authority making assertions on user identity
      • Service provider:
        • The consumer of identity - acting as an authorization authority granting access (or not).
    • Corresponding domains are assumed to be autonomous:
      • Identity stores are assumed to be managed separately.
    • In traditional approaches, identity and service providers are confined in the same domain, i.e. service providers are restricted to identities from the same domain.
    Identity provider issues consumes digital identity Domain A Domain B Service provider
    • Examples:
    • Government
    • Enterprises
    • Communities
    • Individuals
    • Examples:
    • Applications
    • Web sites
    • Portals
  • 9. Setting the Scene How to Accommodate IAM? Where to accommodate IAM? Which IAM concepts and services to support? Which IAM technologies to implement? How to architect this cross-cutting concern? … Application 1 Application 2 Application 3 SOA framework … Applications Framework
  • 10. Setting the Scene Where to Accommodate IAM?
    • Prerequisite: the framework encapsulates cross-cutting concerns of the SOA system e.g.
      • Supply of a container with life-cycle functionality for components
      • Support for service registration and discovery
      • Support for interactions between services
    • Proposition: IAM is one of the cross-cutting concerns that are to be supported by the framework. Without such support:
      • A zoo of “do it yourself” authorization solutions will emerge on application level. This will lead to excessive design, development, training, and maintenance efforts.
      • Another zoo of “do it yourself” authentication solutions will proliferate. This will lead to islands of isolated identity resp. subsequent integration problems.
    • Conclusion:
      • The IAM base functionality needs to be provided by the framework
      • Applications employ this framework-offering according their specific needs.
  • 11. Setting the Scene Which IAM Concepts and Services to Support ?
    • Authentication and SSO:
      • Initial authentication
      • Local domain SSO
      • Cross domain SSO and identity federation
    • Authorization and privacy:
      • Authorization for service invocations:
      • Authorization for operations on application objects:
      • Self-management, user consent, opt-in/opt-out
        • Sample use case: needs to be authenticated (to use the services and resources of the SOA system)
        • Sample use case: simultaneously logon to all services of a SOA system
        • Sample use case: transparently sign-on as Windows user
        • Sample use case: needs to be administrator to update service bundle
          • Here: only administrators may call method update in service ContainerUpdate
        • Sample use case: needs to be “self” to change buddylist
          • Here: everybody may call method addBuddyToList in BuddyListManagement but only “self” may change the requested application object
        • Sample use case: needs to be entitled by the owner to obtain presence data
  • 12. Technology Scouting Traditional vs. Emerging Technologies
    • Various traditional exist in IT-security:
      • Working fine
      • Thoroughly discussed and tested
    RBAC COPS Capability List RADIUS MAC Kerberos ... ACL DAC WSPL XACML EPAL WS-Policy Shibboleth XrML SAML ...
    • Now XML technologies emerge. Questions:
      • What‘s new?
      • Who needs them?
      • Should we care?
  • 13. Technology Scouting Traditional Technology Offerings
    • Authentication and SSO:
      • Initial authentication
        • Various. In Web environments: SSL/TLS client authentication, SPNEGO/Kerberos-in-HTTP, HTTP basic authentication, and HTML form authentication
      • Local domain SSO
        • Kerberos, PKI
      • Cross domain SSO and identity federation
        • Kerberos, PKI
    • Authorization and privacy:
      • Authorization for service invocations:
        • DAC/MAC/RBAC
      • Authorization for operations on application objects:
        • DAC/MAC/RBAC
      • Self-management, user consent, opt-in/opt-out
        • No dedicated technology
    : Deficient : Partial : Mature
  • 14. Technology Scouting Limitations of Traditional Authentication Technologies
    • Kerberos
      • Tightly couples initial and subsequent authentication
      • Requires the same subject identity in communications between Kerberos clients and KDCs and between Kerberos clients and target servers.
      • Kerberos tickets lack metadata on the initial authentication: they do not report the method of initial authentication.
      • Kerberos tickets are scoped to dedicated targets and cannot be presented to arbitrary target servers.
      • Unconditionally trusted authority
    • PKI
      • Supports initial authentication on base of e.g. SSL/TLS but does not transfer authentication state between endpoints.
      • Lacks ability to synchronously assert the authenticated identity of a user across between domain boundaries .
  • 15. Technology Scouting Limitations of Traditional Authorization Technologies
    • DAC (incl. ACLs and capability lists)
      • Traditional operating system mechanisms have scoping and expressiveness limitations in describing authorized subjects (regarding e.g. subjects from external domains) and resources (regarding e.g. resources composed from multiple atomic objects).
      • Does not support relationship-aware authorization which is required to support federation-specific use cases such as resource must be assigned to company A, B, etc. to allow access for a company A, B, etc. manager
    • MAC
      • Does not support identity-centric and relationship-aware authorization.
      • The assignment of single security clearance and label values does not cover scenarios, where users act with different entitlements in different contexts.
    • RBAC (NIST, ANSI/INCITS 359-2004 )
      • Defines an authorization model but no authorization policy and decision query technology
      • Does not support identity-centric and relationship-aware authorization.
      • The single dimension of roles not scale when the assignment of authorizations depends on multiple factors, such as functional subject role and resource affiliation.
  • 16. Technology Scouting Emerging Technology Offerings
    • Authentication and SSO:
      • Initial authentication
        • No dedicated technology
      • Local domain SSO
        • SAML (actually designed for cross-domain SSO and identity federation)
      • Cross domain SSO and identity federation
        • SAML, Shibboleth, Liberty-Alliance, WS-Federation, WS-Trust (STS)
    • Authorization and privacy:
      • Authorization for service invocations:
        • XACML
      • Authorization for operations on application objects:
        • XACML
      • Self-management, user consent, opt-in/opt-out
        • XACML, EPAL, P3P
    : Deficient : Partial : Mature
  • 17. Technology Scouting Emerging Authentication Technologies: SAML
    • General-purpose language to express identity-related security information across autonomous domains:
      • Version 1.0: OASIS Standard, November 2002
      • Version 2.0: OASIS Standard, March 2005
    • Designed to work in federated environments.
    • Supports cross-domain SSO as well as identity federation.
    • Delivers the base technology for Liberty-Alliance and Shibboleth
    • Can integrate existing authentication and authorization systems:
      • Identity provider domain: integrating existing initial authentication and SSO systems
      • Service provider domain: integrating existing SSO and authorization systems
  • 18. Technology Scouting Emerging Authorization Technologies: XACML
    • General-purpose language to express authorization policies and decision queries:
      • Version 1.0: OASIS Standard, February 2003
      • Version 2.0: OASIS Standard, February 2005
    • Supports identity-centric, category-aware, and relationship-aware authorization models
    • Covers the authorization concepts of DAC, MAC, and RBAC and allows to express ACLs as well as capability lists
    • Designed to work in centralized, distributed, and federated environments.
      • Federated environments demand relationship-aware authorization to cover mainline use cases such as Resource must be assigned to company A, B, etc. to allow access for a company A, B, etc. manager
    • Integrates with existing applications and repository systems:
      • No restrictions on actual authorization query language
      • No restrictions on what supplies attribute information
      • No restrictions on authorization policy transport, storage, etc.
    • Is extensible: new attribute types, new functions
  • 19. Security Architecture of the SOA Framework Design Philosophy
    • Do first things first: authentication follows authorization; secure communication follows authentication
    • Don’t evangelize the authorization model: support application-specific models
      • Traditional authorization technologies specialize in dedicated authorization models (e.g. DAC, MAC, RBAC) but applications of a SOA framework demand support for their specific authorization models.
    • Don’t create monoculture: support multiple mechanisms for user authentication
    • Don’t lock-in customers: integrate external security domains such as the ubiquitous Windows domains
    • Avoid dead-ends : support identity federation; enable authentication and authorization to serve federated environments
    • Remove burden from applications : encapsulate the security functionality; support easy deployment in applications
    • Express authorization policies declaratively : reduces effort of embedding authorization into applications. Allows centralized control and proof of regulatory compliance.
  • 20. Security Architecture of the SOA Framework Which IAM Technologies to Implement?
    • Authentication and SSO:
      • Initial authentication
      • Local domain SSO
      • Cross domain SSO and identity federation
    • Authorization and privacy:
      • Authorization for service invocations:
      • Authorization for operations on application objects:
      • Self-management, user consent, opt-in/opt-out
        • SSL/TLS client authentication, SPNEGO/Kerberos-in-HTTP, HTTP Basic, and HTML Form authentication
        • Online authentication authority service using long-lived and short-lived authentication statements
        • Kerberos, SAML, Shibboleth
        • Security interceptor employing an XACML-based policy engine
        • XACML-based policy engine facilitating application-specific authorization models (esp. identity-specific [DAC], category [MAC / RBAC], and relationship-aware authorization)
        • End user-maintained authorization policies
  • 21. Security Architecture of the SOA Framework How to Architect this Cross-Cutting Concern? Caller (e.g. Web-tier) Business delegate SOA framework Business service SOA framework Policy engine (PDP) Attribute handlers (opt.) PEP Message with authentication statement Authentication verifier Authenticated subject ID and attributes Various authentication methods and domains of identity Message Authentication authority SOA framework Attribute handlers (opt.) Federation manager Identity information Caller (e.g. Web-tier) Business delegate SOA framework
  • 22. Security Architecture of the SOA Framework Deployment Options
    • Authentication and SSO:
      • Various authentication methods may be deployed including basic user authentication and integrated Windows authentication.
      • The federation manager is responsible for identity mapping (e.g. external identifier  internal identifier  internal identifier plus attributes). Various attribute handlers may be deployed underneath the attribute collector.
        • The resources of the domain and user repository are provided as a service. Corresponding attribute handlers (e.g. KerberosFederationHandler ) interact via business delegates with this service (not shown).
    • Authorization and privacy:
      • Application-level authorization (shown above)
        • Requires application-specific, programmatic deployment
          • Applications needs to integrate a PEP
        • Allows to control access on arbitrary abstractions supported by the application
      • Interceptor-level authorization (not shown above)
        • Supports application-transparent, declarative deployment
          • Declaration (plus supply of an authorization policy) is sufficient
        • Allows to control access on method invocation-level for arbitrary services
  • 23. Conclusions
    • Identity and access management are cross-cutting concerns in SOA systems.
      • They deliver authorization, authentication and federation:
        • Authorization represents the fundamental service in IT-security. It is mandatory whenever IT-systems handle assets.
        • Authentication delivers the baseline service in cryptographic security. SSO builds upon authentication by transferring authentication state.
        • Federation enables identity integration across autonomous domains with separately managed identity stores.
    • There are traditional and emerging technology offerings:
      • Traditional technology offerings focus on intra-enterprise services.
      • Emerging technologies complement them in inter-enterprise scenarios. They focus on the paradigm of federation. Federation facilitates the use of identity across enterprise boundaries.
    • The security architecture of the SOA framework at Siemens Com is built around authorization, authentication/SSO, and federation. It employs both established, traditional technologies as well as cutting-edge, emerging technologies.
  • 24. Abbreviations
    • ACL Access Control List
    • COPS Common Open Policy Service
    • DAC Discretionary Access Control
    • EPAL Enterprise Privacy Authorization Language
    • IAM Identity and Access Management
    • KDC Key Distribution Center
    • MAC Mandatory Access Control
    • P3P Platform for Privacy Preferences
    • PDP Policy Decision Point
    • PEP Policy Enforcement Point
    • PKI Public Key Infrastructure
    • RADIUS Remote Authentication Dial In User Service
    • RBAC Role-Based Access Control
    • SAML Security Assertion Markup Language
    • SOA Service Oriented Architecture
    • SPNEGO Simple and Protected Negotiation
    • SSL Secure Sockets Layer
    • SSO Single Sign On
    • TLS Transport Layer Security
    • WS Web Services
    • WSPL Web Services Policy Language
    • XACML eXtensible Access Markup Language
    • XML eXtensible Markup Language
    • XrML eXtensible rights Markup Language
  • 25. Authors
    • Dieter Hemkemeyer Siemens AG Com ESY HD PS [email_address]
    • Oliver Pfaff Siemens AG Com ESY SEC DI 5 [email_address]