Harshavardhan Achrekar - Grad Student Umass Lowell presents 1 Scenarios Authentication Patterns Direct Authentication v/s Brokered Authentication Kerberos X.509 PKI STS

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. 2 Introduction

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. 3

Important Concepts  Brokered authentication Trusted authority is used to broker authentication services between a client and a service.  Client 1 ) 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) 4

 Direct authentication Service validates credentials with an identity store, such as a database or directory service.  Impersonation Act 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 security Information related to security (like credentials) is encapsulated in the message.  Mutual authentication Client authenticates the server in addition to the server that authenticates the client. 5

 Security token 1 ) Credentials Implementers 2 ) Contain additional information that is specific to the authentication broker that issued the token.  Service A Web service that requires authentication.  Transport layer security Approach where security protection is enforced by lower level network communication protocols.  Trusted subsystem 1 ) 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. 6

Decision Criteria in Common Scenarios  Public Web service 1 ) 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-business A B2B solution that uses 1 ) Message layer security with the Kerberos protocol within the organization 2 ) X.509 certificates between businesses.  Multiple Internet Web services Security Token Service (STS) for a travel agency application. Uses 1 ) direct authentication and 2 ) brokered authentication 7

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. 8

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. 9

10

Candidate Solution 11

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. 12

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. 13

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. 14

Solution Approach 15

16

Candidate Solution 17

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. 18

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

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. 20

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

Summary of Security Decisions 22

Candidate Solution 23

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. 24

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 searching and booking travel packages.  The travel booking Web application is accessible from the Internet. 25

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 26

Solution Approach 27

28

Candidate Solution 29

 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. 30

 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. 31

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. 32

Authentication Patterns 33

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. 34

 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. 35

Authentication Decision Matrix 36

Brokered Authentication Options - Security Token Decision Matrix 37

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 identity No 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. 38

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.) 39

Brokered Authentication  Forces The client accesses additional services, which results in the need for a single sign on (SSO) solution. No Trust Between 1 ) The client and the Web service 2 ) 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. 40

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

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. 42

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. 43

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 44

 Account database Identity store to check client credentials presented for authentication. Master keys for the client and service are also stored in this database.  Kerberos policy 1 ) user logon restrictions 2 ) service ticket lifetime 3 ) user ticket lifetime 4 ) clock synchronization 45

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. 46

Client Authenticates with Service 47 Concentrate

 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. 48

 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. 49

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. 50

Solution Participants  Certificate authority (CA) A CA is an authentication broker that is responsible for authenticating clients and issuing valid X.509 certificates.  Certificate store This is where the X.509 certificates are located.  Client  Service 51

Process  A mutually trusted CA must issue an X.509 certificate. You can obtain an X.509 certificate in one of the following ways:  ● Purchase an X.509 certificate from a public CA.  ● Configure a PKI server, such as Windows Certificate Services, to create an X.509 certificate, and then use the PKI CA to sign the certificate.  ● MakeCert tool create a self-signed certificate.  The actual process of issuing and distributing X.509 certificates is beyond the scope of this presentation. 52

53  1. The client sends a message to the service. The message includes the client’s credentials, signed with the private key that is paired with the public key in the client’s X.509 certificate.  The client can also attach its X.509 certificate to the message else it attaches a certificate identifier to the request message so that the service can retrieve the client’s X.509 certificate from a certificate repository.

 2. The service validates the certificate, by performing checks, including:  ● Verifying that the certificate has not expired. -expiration date in the certificate is past the current date  ● Verifying that the certificate is internally consistent. -By verifying the certificate contents against the signature of the issuing CA.  ● Verifying the issuing CA of the client’s X.509 certificate. This is done by comparing the issuer signature on the user’s X.509 certificate with the X.509 certificate of the issuing CA. 54

 ● Verifying that the issuing CA has not revoked the certificate. X.509 certificate does not appear on a certificate revocation list (CRL) published by the issuing CA by directly accessing it from the CA or by checking against a CRL that was previously downloaded from the issuing CA.  3. The service uses the public key in the client’s X.509 certificate to verify the client’s signature. Thus 1 ) service to authenticate the client 2 ) ensure that the signed data has not been tampered with after the message was signed.  4. (Optional) The service may send a response back to the client. 55

Brokered Authentication: Security Token Service (STS) Forces  Clients requiring authentication require interoperability between those platforms.  Firewalls (ports) protected organizational boundary. Participants  Client  STS The STS is the Web service that authenticates clients by validating credentials that are presented by a client and issue a security token for a successfully authenticated client.  Service 56

Process 57

 1. The client sends authentication request to the STS in the form of an RST message. This step can be performed by presenting the client’s identifier and proof-of-possession.  The RST message contains a security token that holds the client’s credentials, which are required to authenticate the client.  The specific security mechanism used for securing the RST depends on the relationship between the client and the STS.  2. The STS validates the client’s credentials and issue a security token for the authenticated client. For example, the STS may have a policy where it issues tokens only for users who belong to a specific role. 58

 3. If the client’s credentials are successfully validated, the STS issues a security token (such as a SAML token) in an RSTR message to the client; typically, the security token contains claims related to the client.  When the security token is signed by STS, the service can confirm that the token was issued by the STS and that the security token was not tampered with after it was issued.  4. The client initializes and sends a request message to the service that includes the issued security token.  5. The service validates the security token and processes the request.  6. (Optional) The service initializes and sends a response message to the client. 59

Conclusion  Overview  Common Scenarios  Authentication Patterns  Direct Authentication v/s Brokered Authentication  Brokered Authentication: Kerberos  Brokered Authentication: X.509 PKI  Brokered Authentication: Security Token Service (STS) 60