Disclaimer. SAP 2008 / SAP TechEd 08 / SIM202 / Page 2

Transcription

1 SIM202 SAML 2.0 and Identity Federation Yonko Yonchev, NW PM Security SAP AG Dimitar Mihaylov, NW Security and Identity Management SAP Labs Bulgaria Tsvetomir Tsvetanov, Active Global Support SAP America

2 Disclaimer This presentation outlines our general product direction and should not be relied on in making a purchase decision. This presentation is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or to develop or release any functionality mentioned in this presentation. This presentation and SAP's strategy and possible future developments are subject to change and may be changed by SAP at any time for any reason without notice. This document is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this document, except if such damages were caused by SAP intentionally or grossly negligent. SAP 2008 / SAP TechEd 08 / SIM202 / Page 2

3 Agenda 1. What is Identity Federation 2. SAML 2.0 and Identity Federation 2.1 Federation and SSO use cases 2.2 SAML 2.0 for Web application SSO and Federation 3. SAML 2.0 on the SAP NetWeaver Roadmap SAP 2008 / SAP TechEd 08 / SIM202 / Page 4

4 Identity Federation in Wikipedia SAP 2008 / SAP TechEd 08 / SIM202 / Page 5

5 Identity Federation Formalized in Standard Definitions SAP 2008 / SAP TechEd 08 / SIM202 / Page 6

6 Identity Federation: More Than Just Cross Company SSO Airline 2. Carry over Mary s identity??? Hotel 1. Book flight as registered travel agency customer 2. Need hotel accommodation Authenticate users across multiple IT systems and/or organizations Use negotiated identifiers to assemble identity from user information, stored across distinct organizations Collaborate on a contract-basis with contracts defining responsibility boundaries and requirements. Mary Single Sign On (SSO), Single Log- Out (SLO), access policy provisioning across autonomous security domains Use contractual agreement on how to refer to the user as configuration input Support different technical flavors: user controlled or enterprise controlled desktop oriented or service oriented Technical View SAP 2008 / SAP TechEd 08 / SIM202 / Page 7

7 Terms and Concepts: Roles of the Information Systems Involved in Identity Federation Identity Provider (IdP) Authoritative site with responsibility to authenticate end users and assert their identity information in a trusted fashion to trust partners Responsible for management of the user identity lifecycle Service Providers (SPs) Have a trust relationship to an IdP to accept and trust asserted information provided by the IdP on behalf of a user Delegate identity lifecycle and access management load to IdP May still manage local information for a user (e.g. SP-side service specific attributes and personalization related information) A Service Provider (e.g. a Portal) can function as an IdP for other SPs Trust Relationship Identity Provider (IdP) Federation Service Providers (SPs) SAP 2008 / SAP TechEd 08 / SIM202 / Page 8

8 Terms and Concepts: Identity Identity: The essence of an entity, often described by one's characteristics, traits, preferences and attributes Anonymity: Having an identity that is unknown or concealed Identifier: A data object that uniquely refers to a particular entity Pseudonym: A privacy-preserving identifier User Id: user account identifier for a particular system Federated identity: Existence of an agreement between providers on a set of identifiers and/or attributes to use to refer to a principal Account linkage: Relating a principal's accounts at two different providers so that they can communicate about the principal SAP 2008 / SAP TechEd 08 / SIM202 / Page 9

9 Terms and Concepts: Identity Attributes Classes of attributes that describe an identity Authentication credentials: e.g. account id, password, one-time PIN Transaction attributes: part of authentication process, e.g. group memberships, customer ID, organizational roles Profile attributes: information not tied to authentication process, e.g. address, home address, birth date Provider-specific attributes: user preferences, buying history Provisioning Authentication Credentials shared / distinct Authentication Credentials Transaction Attributes shared Transaction Attributes Profile Attributes shared Profile Attributes IdP Identity Provider-spec. Attributes distinct Provider-spec. Attributes SP Identity SAP 2008 / SAP TechEd 08 / SIM202 / Page 10

10 Identity Federation: Identity Models Distinct Identity Model Full Identity data initially provisioned across systems e.g. with a Virtual Directory Server Accounts managed independently according to IdP and SP functional requirements Shared Identity Model User Identity Providers (IdP) and federated Service Providers (SP) agree on a common unique identifier (aka Alias, Pseudonym or Opaque Id) used to refer to the user Sharing authentication credentials means that the SP can rely upon IdP to authenticate the user Requires user consent on shared attributes SAP 2008 / SAP TechEd 08 / SIM202 / Page 11 Full set of distinct attributes Identity Provider (IdP) e.g. Portal server, AS Java shared attributes distinct attributes Identity Provider (IdP) e.g. AS Java provisioning user identities from Identity Center Federation Trust Relationship Federation Trust Relationship Full set of distinct attributes Service Provider (SP) e.g. Portal, AS ABAP, AS Java, distinct attributes Service Provider (SP) e.g. Portal, AS ABAP, AS Java,

11 Identity Federation: IdP, SP and Identity Models as a Reflection of Real-life Governments as Identity Provider Governments are an Identity Provider because they issue a Passport as proof of identification Every country vouches for its citizens Governments as Service Provider When an USA citizen travels to Germany, Germany verifies the identity of the USA citizen by checking its passport. Germany trusts the Identity Provider (USA) to vouch for all its citizens. It still makes its own access control decision (to let the person in or not) based on identity data (including attributes) that is being asserted USA Government (Identity Provider) Trusted Relationship German Government (Service Provider) SAP 2008 / SAP TechEd 08 / SIM202 / Page 12

12 Identity Attribute Sharing: Contracts Define What can be Shared For business or privacy legislation reasons not all identity information may be transmitted to remote systems. The contract provides a skeleton about the information that can be shared. In the case of trust established indirectly via intermediary brokers, the contract may even include special agreements per target system or target system group. Ideally for data protection and privacy reasons, the user (administrator or normal user) is able to: Assign and audit policies for different trust relationships, or be queried for the data that is requested from the federation authority (user identity provider) by the accessed via federation resource (service providers) Enforce contractual agreement with security solutions for integrity and confidentiality protection, or cryptographic mechanisms SAP 2008 / SAP TechEd 08 / SIM202 / Page 13

13 Contracts and Trust in Federation Agreements Contracts underlie trust in business can be negotiated off-line or via the technology. Contractual agreements must include effective measures for non-repudiation and enforcement to maintain trust The trust contract may be a pair wise (point-to-point) agreement between different parties or different contracts between each party and common or different brokers (star-like trust setup) Direct Authentication Indirect Business Agreements Direct Indirect None Pair wise Direct Pair wise Indirect Brokered Direct Brokered Indirect Community Direct Community Indirect SAP 2008 / SAP TechEd 08 / SIM202 / Page 14

14 Identity Federation: Protocol Characteristics Employment of effective cryptographic means for non-repudiation and trust enforcement Securely Identify Trusted Systems: use system certificates and public keys to securely and effectively identify systems involved as user agents in federated transactions Digital Signatures: warrant message integrity and non-repudiation Message Encryption: warrant confidentiality of exchanged information Push and Pull Single Sign-On Push SSO: SSO exchange is triggered by a request to the Identity Provider, which pushes a Security Token to the Service Provider Pull SSO: SSO exchange is triggered by a request to the Service Provider, which then pulls a Security Token from the Identity Provider Account Linking Link distinct identity accounts to provide Single Sign-On IdP and SP agree on some common unique identifier (CUID) and bind each of their internal, local user identities to this CUID Allows IdP and SP to refer to the user by their CUID during SSO without disclosing information about their local internal representation of the user SAP 2008 / SAP TechEd 08 / SIM202 / Page 15

15 Identity Federation: Protocol Characteristics Account de-linking (de-federation) Deletion of the common unique identifier for a federated user Removes ability to SSO with SP Where are you from (WAYF) Persistent information associated with the user (such as an HTTP cookie) to identify to which IdP an SSO request from the SP is to be directed (in the case where SP has trust relationship with multiple IdPs) Session Management Session Management of the user s local session at the SP(s) after single signed-on such as logoff or session time-out (session lifetime / inactivity time) Single Logout User-initiated global logout of all sessions asserted by a given identity provider IdP is responsible for maintaining a list of all SPs to which the user has been SSO-ed in a given session. IdP sends a logout request to each of these SPs on behalf of the user SAP 2008 / SAP TechEd 08 / SIM202 / Page 16

17 SAML Overview An XML Framework for marshaling security and identity information and exchanging it across administrative domain boundaries SAML profiles describe a variety of use cases using the framework SAML Core technology: Assertions about subjects Assertions contain statements: Authentication, Attribute, Authorization Decision Entity (or system entity): An active element of a computer/network system Principal: An entity whose identity can be authenticated Subject: A principal in the context of a security application SAP 2008 / SAP TechEd 08 / SIM202 / Page 18

18 SAML 2.0 Terms and Concepts: System Roles Asserting party (SAML authority): An entity that produces SAML assertions Identity provider: An entity that creates, maintains, and manages identity information for principals and provides principal authentication to other trusted service providers Relying party: An entity that use received assertions and decides to take an action based on the information Service provider: An entity that provides services to principals or other entities and has an established trust association to an Identity Provider SAP 2008 / SAP TechEd 08 / SIM202 / Page 20

19 SAML 2.0 in a Nutshell SAML 2.0 System Roles in Perspective IdP Identity Provider (asserting role) [Externally] Authenticates the user Produces assertions to transfer a user's identity to service providers optionally transfer additional user attributes to service providers Keeps track of the service providers that have received assertions for a certain user SP Service Provider (relying role) Offers services/resources to users Consumes assertions The SAML 2.0 Protocol Deliverables Profiles Combinations of assertions, protocols and bindings to support a specific use case Bindings Mappings of the SAML Protocols onto standard messaging and communication protocols Protocols Requests and Responses for obtaining assertions and doing identity management Assertions Authentication, Attribute and entitlement information Authentication Context Detailed data on type and strength of initial authentication Metadata Configuration data for Identity and Service providers SAP 2008 / SAP TechEd 08 / SIM202 / Page 21

20 SAML 2.0 Use Cases: Single Sign-On Account Mapping Assignment of users with same user ID Example: Account Linking Opaque-ID Local UName SP bob sp.com Opaque-ID Local UName bob123 IdP IdP.com joe xyz.com alice abc.com Account Linking Opaque Id-based linking of users with different user IDs Attribute Federation Supports rule based authentication at SP Authentication with defined attributes User Agent (Browser) Browser Identity Store bob SSO request to SP with target (TARGET= ) 1 authentication request 2 Authentication at IdP as bob 3 Artefact Artifact Artefact Artifact Redirect to target ressource 7 IdP 4 <ArtifactResolve> 5 <ArtifactResponse> 6 Use service as bob123" SP Identity Store bob123 SAP 2008 / SAP TechEd 08 / SIM202 / Page 22

21 SAML 2.0 Use Cases: Persistent Federation Establish a permanent, long-term federation IdP and SP share only <NameID> - SP logs in user account that is locally mapped to the asserted by IdP <NameID> Local User ID SP NameID bob sp.com bob qwe.com joe xyz.com Access Resource 2 SP IdP <AuthnRequest> using Redirect (@Format= nameid-format:persistent ) 3 Credential Challenge Create Security 4 Context User login as bob 5 user action or (auto) submit SAP 2008 / SAP TechEd 08 / SIM202 / Page 23 HTML Form with <Response> (NameID= ) User Agent (Browser) Local User ID IdP NameID bob123 IdP.com bob123 IdpXYZ.net alice idpabc.com Check if NameID already HTTP Post <Response> maps to local account 7 Credential Challenge & Opt-in? 8 Provide credentials for account bob123 9 Resource HTTP Redirect with Cookie identifying local session)

22 SAML 2.0 Use Cases: Transient Federation User not required to provide credentials at SP Federation at SP not intended to be managed on a long term basis Local User ID bob joe sue tom IdP Create Security Context SAP 2008 / SAP TechEd 08 / SIM202 / Page 24 Status Gold Gold Silver Silver User Agent (Browser) Local User ID GoldUser SilverUser 1 Access Resource 2 <AuthnRequest> using Redirect (@Format= nameid-format:transient ) 3 Credential Challenge 4 User login with bob 5 user action or HTML Form with (auto) submit <Response> 6 (NameID=<generated>, HTTP Post <Response> Status=Gold) 7 Resource (HTTP Redirect with Cookie identifying local session) SP Validate IdP Signature Log in SP account GoldUser, according to local SP attribute mapping rules

23 SAML 2.0 Single Logout User previously authenticated at IdP User is interacting with SP1 and SP2 and terminates session with SP1 SP1 sends <LogoutRequest> with user <NameID> and <SessionIndex> via HTTP Redirect IdP determines that other SPs are participating in the session and sends <LogoutRequest> to SP2 (using a different protocol binding, e.g. SOAP) User Agent (Browser) 2 1 IdP SP1 SP2 Select Logout <LogoutRequest> via HTTP Redirect <LogoutRequest> via SOAP over HTTP 4 <LogoutResponse> via SOAP over HTTP 5 <LogoutResponse> via HTTP Redirect 3 SAP 2008 / SAP TechEd 08 / SIM202 / Page 26

24 Demo 1 Setup: Browser SSO and Federation with SAML 2.0 POST in Company Extranet Enterprise (Security Domain A) Travel Agency (Security Domain B) WatsonM outsources business to AccountXYZ Enterprise Portal employee of needs access to Travel Agency Web site Mary Watson SAP 2008 / SAP TechEd 08 / SIM202 / Page 27

25 SAP 2008 / SAP TechEd 08 / SIM202 / Page 28 DEMO

26 SAML 2.0 POST Web Browser SSO: Behind the Curtains 1. Service request (protected access) 2. Service needs authentication 3.<SAMLRequest> in POST (HTTP Body) in a HTML Form 4. Login request of IdP 5. Send Credentials 6. Send SAML-Assertion as <SAMLResponse> with secured user name identifier in HTTP Body User Agent (Browser) 7. Forward <SAMLResponse> as POST parameter to Assertion Consumer Service of SP Resource 8. Send data of the service to the user Resource SAP 2008 / SAP TechEd 08 / SIM202 / Page 29

27 Demo 2 Setup: Browser SSO and Federation in Company Intranet with SAML 2.0 Browser Artifact Local Subsidiary (Administrative Domain A) ERP (Administrative Domain B) WatsonM Uses systems from finance department AccountXYZ Enterprise Portal employee of needs access to Browser-enabled Budgeting application Mary Watson SAP 2008 / SAP TechEd 08 / SIM202 / Page 33

28 SAP 2008 / SAP TechEd 08 / SIM202 / Page 34 DEMO

29 SAML 2.0 Browser Artifact Web Browser SSO: Behind the Curtains 1. Service request (protected access) 2. Service needs authentication 3. <AuthnRequest> Redirect/Post 4. Login request of IdP 5. Send Credentials 6. Transfer SAMLart Browser Artifact in GET (HTTP redirect) 7. Send SAMLart as URL parameter to SP 8. SOAP request to Assertion Resolution Service in IdP 9. Answer with a SAML-Assertion, containing secured user name identifier 10. Send data of the service to the user SAP 2008 / SAP TechEd 08 / SIM202 / Page 35 User Agent Client (Browser) 5 Login Login request 4 SAMLart 6 <AuthnRequest> 3 <ArtifactResolve> SAMLart 7 Ressource Resource 10 <AuthnRequest> 2 1 Service request Single Logout Service (SLO) Single Sign-On Service (SSO) Artifact Resolution Service (ARS) 8 9 Assertion Consumer Service (ACS) Single Logout Service (SLO) Resource Ressource Identity Provider -Lite - <ArtifactResponse> Service Provider -Lite -

31 Current Support for SAML in SAP NetWeaver SAML Browser Artifact Scenario for desktop application SSO NW 04 NW 7.00 NW 7.10 SAML 1.1 Accepting SAML Assertions Java X X X SAML 1.1 Accepting SAML Assertions - ABAP - - X SAML 1.1 Issuing SAML Assertions CE Portal - - X Limitations: Authorization Information is not supported Authentication scenarios only Use SSL for Transport Security WSS SAML Token Profiles 1.0 for SSO and user id propagation for WS access NW 04 NW 7.00 NW 7.10 Sender Vouches Subject Java - - X Sender Vouches Subject - ABAP - X (SP14 and higher) X SAP 2008 / SAP TechEd 08 / SIM202 / Page 40

32 Security and Identity Management Roadmap Highlights Role & Authorization Mgmt. Identity Management Enterprise SOA and Standards Security Management Meta-roles definition and assignment Central Identity Management for heterogeneous landscapes Standards-based principal propagation Enhanced support for WS-* standards Harmonization of security administration Role management Harmonized simplification and authorization TCO reduction Support planned for concepts Web browser SSO and Identity Federation scenarios with SAML 2.0 Business process IdP-Lite and SP-Lite Business role integrated identity management management Standards-based single sign-on infrastructure (SAML) Identity federation support (SAMLv2) Add. WS-* standards (WS-Sec.Conversation, WS-Trust) Centralized policybased security administration Extended SOA scenario support Model driven security management SAP 2008 / SAP TechEd 08 / SIM202 / Page / and beyond 2009

33 Lite Protocol Interoperability Matrix from Liberty SAP 2008 / SAP TechEd 08 / SIM202 / Page 42 Feature IDP IDP-Lite SP SP-Lite Web SSO, <AuthnRequest>, HTTP redirect MUST MUST MUST MUST Web SSO, <Response>, HTTP POST MUST MUST MUST MUST Web SSO, <Response>, HTTP POST MUST MUST MUST MUST Artifact Resolution, SOAP MUST MUST MUST MUST Enhanced Client/Proxy SSO, PAOS MUST MUST MUST MUST Name Identifier Management, HTTP redirect (IDP-initiated) Name Identifier Management, SOAP (IDP-initiated) MUST MUST NOT MUST MUST NOT MUST MUST NOT OPTIONAL MUST NOT Name Identifier Management, HTTP redirect MUST MUST NOT MUST MUST NOT Name Identifier Management, SOAP (SP-initiated) MUST MUST NOT OPTIONAL MUST NOT Single Logout (IDP-initiated), HTTP redirect MUST MUST MUST MUST Single Logout (IDP-initiated), SOAP MUST OPTIONAL MUST OPTIONAL Single Logout (SP-initiated), HTTP redirect MUST MUST MUST MUST Single Logout (SP-initiated), SOAP MUST OPTIONAL MUST OPTIONAL Identity Provider Discovery (cookie) MUST MUST OPTIONAL OPTIONAL

34 Future Scenarios Services Based Federation Office Application (Administrative Domain A) ERP (Administrative Domain B) integrates functionality of AccountXYZ WatsonM uses needs access to Mary Watson SAP 2008 / SAP TechEd 08 / SIM202 / Page 46

35 Holder of Key Subject Confirmation for WSS SAML Tokens Planned for Future Releases Service Consumer: 1. Identify Logical Port configuration for service consumption 2. Request SAML assertion from pre-configured SAML Assertion Issuer 3. Return SAML assertion (digitally signed) 4. Send Service Request with enclosed SAML assertion SAML Assertion Issuer Service Provider: 5. Verify assertion s digital signature with system X.509 certificate of SAML Assertion Issuer 6. Use assertion for user authentication 7. Return service response on success By decoupling the SAML identity provider from the service consumer, administrators have the option to use a third system to issue SAML assertions X.509 Certificate based trust relationship client application Service call via Logical Port 4. Service Provider Application 6. SAP 2008 / SAP TechEd 08 / SIM202 / Page 47

36 Summarizing the SAML Use Cases at SAP Standardize on SAML for SSO Standards based authentication for Web based applications and Web Services Supporting heterogeneous environments as well Identity Propagation using trusted SAML Identity Provider proxies Single Log Out Federation between different Security Domains (Circles of Trust) Within a company or between companies Including non SAP-Systems Central User Mapping based in IdP functionality Provisioning of Identity Attributes SAP 2008 / SAP TechEd 08 / SIM202 / Page 48

37 Building Your Business with SDN Subscriptions SDN Subscriptions offers developers and consultants like you, an annual license to the complete SAP NetWeaver platform software, related services, and educational content, to keep you at the top of your profession. SDN Software Subscriptions: (currently available in U.S. and Germany) A one year low cost, development, test, and commercialization license to the complete SAP NetWeaver software platform Automatic notification for patches and updates Continuous learning presentations and demos to build expertise in each of the SAP NetWeaver platform components A personal SAP namespace SAP NetWeaver Content Subscription: (available globally) An online library of continuous learning content to help build skills. Starter Kit To learn more or to get your own SDN Subscription, visit us at the Community Clubhouse or at SAP 2008 / SAP TechEd 08 / SIM202 / Page 49

38 Further Information SAP Public Web: SAP Developer Network (SDN): Business Process Expert (BPX) Community: Related SAP Education and Certification Opportunities Related Workshops/Lectures at SAP TechEd 2007 SIM206, SSO in Heterogeneous Systems Landscapes and SAML, Lecture SIM207, Towards Interoperable SSO for Web Services, Lecture SAP 2008 / SAP TechEd 08 / SIM202 / Page 50

39 Thank you! SAP 2008 / SAP TechEd 08 / SIM202 / Page 51

40 Feedback Please complete your session evaluation. Be courteous deposit your trash, and do not take the handouts for the following session. Thank You! SAP 2008 / SAP TechEd 08 / SIM202 / Page 52