Web Service Security in WSE 3.0 - Design Patterns and Practices iws -ii

1. STS Scenarios Harshavardhan Achrekar - Grad Student Umass Lowell presents Authentication Patterns X.509 PKI Web Service Security in WSE 3.0- Design Patterns and Practicesiws-ii Kerberos Direct Authentication v/s Brokered Authentication

2. Introduction What is WSE 3.0 ? • Simplifies the development and deployment of secure Web services. • Enables developers and administrators to apply security policies to Web services running on the .NET Framework 2.0. • Web services communication can be signed and encrypted using Kerberos tickets, X.509 certificates and other custom binary and XML-based security tokens.

3. Web Service Security Discussion includes:- • Choosing between message layer security and transport layer security. • Choosing a client authentication technology, from basic direct authentication to more sophisticated brokered solutions, including an in-depth look at X.509 certificates, using the Kerberos version 5 protocol, and solutions involving a Security Token Service (STS). • Protecting confidentiality of messages. • Detecting tampered messages. • Preventing the processing of replayed messages.

4. Important Concepts • Brokered authenticationTrusted authority is used to broker authentication services between a client and a service. • Client1 ) Access the Web service. 2 ) Provides credentials for authentication during the request to the Web service. • Credentials A set of claims used to prove the identity of a client. They contain 1 ) An identifier for the client 2 ) Proof of the client’s identity, such as a password. 3 ) Include information, such as a signature, to indicate that the issuer certifies the claims in the credential. (Optional)

5. Direct authenticationService validates credentials with an identity store, such as a database or directory service. • ImpersonationAct of assuming a different identity on a temporary basis.Purpose:- A different security context or set of credentials can be used to access a resource. • Message layer securityInformation related to security (like credentials) is encapsulated in the message. • Mutual authenticationClient authenticates the server in addition to the server that authenticates the client.

6. Security token 1 ) Credentials Implementers2 ) Contain additional information that is specific to the authentication broker that issued the token. • Service A Web service that requires authentication. • Transport layer securityApproach where security protection is enforced by lower level network communication protocols. • Trusted subsystem1 ) Use trusted business identity to access resource on behalf of client. 2 ) Service account or identity of an application account created specifically for access to remote resources.

7. Decision Criteria in Common Scenarios • Public Web service1 ) Transport layer confidentiality with HTTPS 2 ) Username Token • Intranet Web service 1 ) Message layer security with the Kerberos protocol for an internal banking solution • Internet business-to-businessA B2B solution that uses 1 ) Message layer security with the Kerberos protocol within the organization 2 ) X.509 certificates between businesses. • Multiple Internet Web servicesSecurity Token Service (STS) for a travel agency application . Uses1 ) direct authentication and 2 ) brokered authentication

8. Public Web Service Scenario • A large clothing distributor wants to provide catalog information of current items to merchants that provide online shopping services. • Web Apps Web Services Catalog Data.

9. Distributor Web Service Profile • A distributor Web service requirements: 1 ) Web application requires direct access to Web service. 2) Authenticated Merchants access the Web service. 3) Data Protection of merchant account information between the merchant and distributor communication.

11. Candidate Solution

12. Implementation: • The distributor Web service uses a server certificate.Establishes secure communications with the merchant Web application using HTTPS. • The merchant Web application passes a Username Token to the distributor Web service for authentication. • Username Token information used to authenticate the merchant Web application. • The distributor Web service uses a trusted subsystem to access catalog data.

13. Intranet Web Service Scenario • A national bank uses Web services to provide operations that are accessed by an internal banking application. • Banking application (Windows client)  Web service  bank account database .

14. Banking Application Requirements 1 ) Used in bank branches. 2 ) User of Application - customer service representative (CSR). 3 ) Authenticate CSR - a valid user to use banking application. 4 ) Banking regulations - account activities that the CSR performs must be audited.

15. Solution Approach

17. Candidate Solution

18. Intranet banking security solution implementation: • The user’s credentials are used to obtain a security token from the Kerberos Key Distribution Center (KDC) implemented in Active Directory. • The security token used to sign and encrypt messages sent to the service. • The security token is used to obtain additional information about the user from Active Directory. • Impersonation with delegation used to access database.

19. Internet B2B Scenario • A supply chain application for Procurement operations • The supply chain application  Procurement Web service (intranet) External ordering Web service (Internet).

20. Supply Chain Management Requirement 1 ) The manufacturing company orders parts from a business partner through an internal line-of-business supply chain management application. 2 ) Application Users-Factory floor supervisors. 3 ) The two Web services have to agree on the external service contract. 4 ) The procurement Web service is one of a few other internal Web services that the supply chain management application uses. SSO user experience mandatory.

21. Solution Approach • Analysis of : Intranet communication and the Internet communication.

22. Summary of Security Decisions

23. Candidate Solution

24. Supply Chain Management security solution implementation: • The user’s credentials used to obtain a security token from the Kerberos KDC implemented in AD. • Use security token to sign & encrypt messages sent to service. The supplier’s security solution is implemented in the following way: • X.509 certificates issued & imported into certificate stores. • X.509 certificates provide mutual authentication, data confidentiality, and data origin authentication between two Web services. • A perimeter service router forwards requests from the supply chain application to the ordering Web service.

25. Multiple Internet Web Services Scenario • A travel booking franchise provides a Web application that travel agents(Users) can use to search for & book travel packages. • Web services to perform searchingand booking travelpackages. • The travel booking Web application is accessible from the Internet.

26. Travel Booking Application Requirement 1 ) Users - Travel agents - help customers book tour packages. 2 ) Travel packages Web service  travel product catalog information such as tour dates, itineraries, and prices.3 ) Online booking Web service  travel agents to book tour packages on behalf of the customers. 4 ) Identity propagation needed Customers can go to any travel agent in the franchise to book a tour. 5 ) Performance issues During peak travel seasons

27. Solution Approach

29. Candidate Solution

30. Use Direct authentication to access Security Token Service (STS) • The security token that is returned would then be used for brokered authentication against the Web services to provide data confidentiality and data origin authentication support. IMPLEMENTATION • The STS uses a server certificate to establish secure communications with Web application using HTTPS. • Web application passes Username Token to STS . • The STS returns SINGLE security token for interaction with both Web services.

31. Encryption is not required  the travel package Web service. However, the STS security token is used to sign the messages to provide authentication and encrypt in online booking Web service. • A trusted subsystem is used to access the product catalog and customer booking database. • Impersonation not required for auditing. • Retrieve agent’s ID from the security token  passed to the customer booking database as part of the request.

32. Authentication Patterns • As computer systems have increased in complexity, the challenge of authenticating users has also increased. As a result, there are a variety of models for authentication. • E.g., Clients accessing a Web application may directly provide credentials , such as a user name and password. • A third-party broker, (Kerberos domain controller),provide security token for authentication. • These two models are referred to as direct authentication and brokered authentication.

33. Authentication Patterns

34. Direct Authentication vs. Brokered Authentication • In trust relationship , exchange and validate credentials including passwords, direct authentication can be performed. • For accessing a company’s stock tracking service, establish an ID and password with the provider then use to call its Web service.

35. Client and service do not share direct trust relationship, use Broker • The broker authenticates the client issues a security token that the service can use to authenticate the client. • Verification - token itself contain proof of a relationship with the broker.

36. Authentication Decision Matrix

37. Brokered Authentication Options - Security Token Decision Matrix

38. Direct Authentication • Forces The credentials that the client presents to the Web service are based on shared secrets, such as passwords. The Web service can validate credentials from the client against an identityNo support for capabilities such as single-sign on (SSO) or support for non-repudiation. The client and the Web service trust one another to manage credentials securely.

39. Process 1. The client sends a request to the Web service, attaching credentials to the request message. 2. The Web service validates the credentials against an identity store and makes authorization decisions about the client. 3. The Web service returns a response to the client. (This step is optional.)

40. Brokered Authentication • ForcesThe client accesses additional services, which results in the need for a single sign on (SSO) solution. No Trust Between1 ) The client and the Web service2 ) The Web service and the Identity store The client and Web service share a standard access control infrastructure. An authentication broker that both parties trust independently.

41. Process 1.The client submits an authentication request to the authentication broker. 2. The authentication broker contacts the identity store to validate the client’ credentials.

42. 3. If authentication successful, issues a security token to Client to authenticate with the service for lifetime of token. 4. A request message is sent to the service; it contains the security token that is issued by the authentication broker. 5. The service authenticates the request by validating the security token that was sent with the message. 6. The service returns the response to the client.

43. Brokered Authentication- Kerberos Forces • multiple users clients call Web services, single sign on (SSO) capabilities and Centralized authentication of clients required. • Interoperability for Clients on different Platforms.Clients may exist in an untrusted network environment. • Extended capabilities associated with a particular implementation of the Kerberos protocol. E.g. Windows Server 2003 implementation of the Kerberos protocol provides capabilities, such as integration with Active Directory.

44. Solution Participants: • Client • Service • Key Distribution Center (KDC) The KDC is the authentication broker that is responsible for authenticating clients and issuing service tickets. On the Windows platform, the KDC is implemented in Active Directory. KDC Components:- 1 ) Account database 2 ) Kerberos policy

45. Account databaseIdentity store to check client credentials presented for authentication. Master keys for the client and service are also stored in this database. • Kerberos policy1 ) user logon restrictions 2 ) service ticket lifetime 3 ) user ticket lifetime4 ) clock synchronization

46. Process • 1. The client is authenticated with the broker, and given access to a ticket-granting ticket (TGT) to request access to a service. • 2. The client uses the TGT to request access to a particular service, and then it receives a service ticket. • 3. The service uses the service ticket to validate credentials. • 4. Clients can be authenticated through a wide variety of techniques, one is Windows integrated authentication used to access a Web application.

47. Client Authenticates with Service Concentrate

48. 1. The client sends a TGT in a message to the KDC to request a service ticket for communication with a specific Web service. • 2. The KDC creates a new session key and service ticket that will be used for communication with the requested service. • The service ticket contains the client’s authorization data and the new session key. The KDC encrypts the service ticket with the Web service’s master key. • The service ticket and encrypted session key are returned to the client. Both the new session key and service ticket represent credentials used to create a security token that allows access to the Web service. • The client decrypts the session key and then uses the key to encrypt an authenticator, which contains a timestamp and other information.

49. The authenticator and session ticket are included in the new Kerberos security token. The session key is not included in the token; however, it is included in the service ticket, which is what the service uses to validate the token. • 3. A request message, which contains the Kerberos security token created in the previous step, is sent to the service. • 4. The service uses its master key to decrypt the service ticket found in the security token and to retrieve the session key. The session key is used to decrypt the authenticator and validate the security token. • 5. (optional)The service returns a response to the client. To provide mutual authentication, the response should contain unique information that is encrypted with the session key to prove to the client that the service knows the session key.

50. Brokered Authentication: X.509 PKI Forces • multiple organizational boundaries • The client and the Web service do not trust each other. • The authentication broker might be offline or unavailable on some occasions. • Clients require interoperability of platforms for authentication. • The organization may need to trace particular actions to a specific client or service.