Web Services Security Two ways to ensure security with Web Services Transport level security such as SSL,

is the usual "first line of defense", as securing the transport mechanism itself makes Web services inherently secure. Message level security, such as WS-Security, SAML, XML Digital Signatures, and XML Encryption, can be more effective and has the added flexibility that the message can be sent over any transport Transport Level Security Transport level security is based on Secure Sockets Layer (SSL) or Transport Layer Security (TLS) that runs beneath HTTP. SSL and TLS provide security features including authentication, data protection, and cryptographic token support for secure HTTP connections Secure Sockets Layer (SSL) is a protocol developed by Netscape for transmitting private documents via the Internet. The SSL is the Industry accepted standard protocol for secured encrypted communications over TCP/IP The SSL protocol provides transport layer security: authenticity, integrity, and confidentiality, for a secure communication across the wire. SSL uses a cryptographic system that uses two keys to encrypt data a public key known to everyone and a private or secret key known only to the recipient of the message. Both Netscape Navigator and Internet Explorer support SSL. Security features provided by SSL are data encryption to prevent the exposure of sensitive information while data flows across the wire. Data signing prevents unauthorized modification of data while data flows across the wire. Client and server authentication ensures that you talk to the appropriate person or machine. SSL can be effective in securing an enterprise environment. SSL operates between communication endpoints, not between applications Transport Layer Security (TLS) is a security protocol from the IETF that is based on the Secure Sockets Layer (SSL) 3.0 protocol developed by Netscape. TLS uses digital certificates to authenticate the user as well as authenticate the network (in a wireless network, the user could be logging on to a rogue access point). The TLS client uses the public key from the server to encrypt a random number and send it back to the server. The random number, combined with additional random numbers previously sent to each other, is used to generate a secret session key to encrypt the subsequent message exchange.

SSL provides endpoint authentication and communication privacy over the internet using cryptography. In this model, a Web Service client will use SSL to open a secure socket to a Web Service. The client then sends and receives SOAP messages over this secured socket using HTTPS. The SSL implementation takes care of ensuring privacy by encrypting all the network traffic on the socket. SSL can also authenticate the Web Service to the client using a digital certificate issued by a Certificate authority. HTTPS to implement Web Services Secuirty HTTPS provides encryption, which ensures privacy and message integrity. HTTPS also authenticates through the use of certificates, which can be used on the server side, the client side, or both. HTTPS with server-side certificates is the most common configuration on the Web today. In this configuration, clients can authenticate servers, but servers cannot authenticate clients. HTTP basic authentication uses a user name and password to authenticate a service client to a secure endpoint. A simple way to provide authentication data for the service client is to authenticate to the protected service endpoint to the HTTP basic authentication. The basic authentication is located in the HTTP header that carries the SOAP request. When the application server receives the HTTP request, the user name and password are retrieved and verified using the authentication mechanism specific to the server. Although the basic authentication data is base64-encoded, sending data over HTTPS is recommended. The integrity and confidentiality of the data can be protected by the Secure Sockets Layer (SSL) protocol. Message Level Security Message level security is an application layer service and facilitates the protection of message data between applications Message level security is typically most useful for: Solutions for which application level security is important; that is solutions whose normal message paths include flows over multiple nodes perhaps connected with different protocols. Message-level security manages trust at the application level, which means security in other layers becomes unnecessary Solutions that are designed to use predominantly asynchronous queues

SOAP based communication introduces the notion of Message Level Security. In message level security, security information is contained within the SOAP message, which allows security information to travel along with the message. For example, a portion of the message may be signed by a sender and encrypted for a particular receiver. When the message is sent from the initial sender, it may pass through intermediate nodes before reaching its intended receiver. In this scenario, the encrypted portions continue to be opaque to any intermediate nodes and can only be

decrypted by the intended receiver. For this reason, message-level security is also sometimes referred to as end-to-end security.

SSL Limitations

SSL is widely used as the security schema in web applications. However, despite its popularity, it has some limitations SSL is designed to provide point-to-point security, which falls short for Web services because we need end-to-end security, where multiple intermediary nodes could exist between the two endpoints. SSL secures communication at transport level rather than at message level. As a result, messages are protected only while in transit on the wire. HTTPS in its current form does not support non-repudiation well. Non-repudiation is critical for business Web services and, for that matter, any business transaction. What is non-repudiation? Non-repudiation means that a communicating partner can prove that the other party has performed a particular transaction. SSL does not provide element-wise signing and encryption. For example, if you have a large purchase order XML document, yet you want to only sign or encrypt a credit card element, signing or encrypting only that element with SSL proves rather difficult. Again, that is due to the fact that SSL is a transport-level security scheme as opposed to a message-level scheme

TRANSPORT LEVEL

MESSAGE LEVEL

Uses SSL

Dose not use SSL

Point-to-Point: Protects the "pipe

Data Chunks are protected

Does not work with Intermediaries

Intended to work with Intermediaries

Ubiquitous

Standards still under development

has been around for a long time

relatively new, offers more features than transport-level

Performance better

has better integration with Web Services standards

Federation Management

Consider the many times an individual accesses services on the Internet in a single day. One person might have a multitude of accounts set up to access various business, community and personal service providers; for example, the person might have used different names, user IDs, passwords or preferences to set up accounts for a news portal, a bank, a retailer, and an email provider. Each time he accesses a service on the Internet, he must log in and identify himself to the service provider. Federation allows for the interchange of security-related information between different entities. Security-related information meaning: authentication, authorization, and auditing data. Although federation is generally used in the context of an interenterprise security mechanism, it can also be used within an enterprise, to provide tighter integration between several loosely-coupled ecosystems. A federation agreement always deals with two entities: An asserting party that generates security assertions, and A relying party that trusts the security assertion made by the asserting party What Is Identity? Identity is a set of attributes that describes a profile of an individual, business organization, or software entity. Identity verification is a dialog of presentation and interpretation. not only people have identities in our network, but also organizations, computers, devices, and systems or applications have identities A local identity refers to the set of attributes or information that identify a user to a particular service provider. These attributes uniquely identify the individual with that provider. For uniquely identify a person, the attributes can include a name, phone number, passwords, social security number, address, credit records, or other identifier. For example, the individual in our scenario is known to his company's network as an employee number, but he is known to his travel agent as Joe Smith. He is known to his online news service by an account number, and he is known to his favorite clothing store by a different account number. He uses one email name and address for his personal email, and a different email name and address for his workplace. Each of these different user names represents a different local identity. Because the Internet is fast becoming the prime vehicle for business, community and personal interactions, it has become necessary to design a system for online users to link their local identities, enabling them to have one network identity. This system is identity federation What Is Identity Federation?

Identity federation allows a user to associate, connect or bind the local identities configured with multiple service providers. A federated identity allows users to login at one service providers site and move to an affiliated service provider site without having to re-authenticate or re-establish their identity. It combines data on a single user from multiple sources, for purposes such as authorization. Since different organizations probably want to use different products to manage the identity data they have, standards are needed to move that data around the networkfrom where it is being held to where it will be used. The Liberty Alliance Project addresses these challenges. Identity Management Architecture An identity management system mediates between identities and resources: it controls identity resource access and facilitates identity resource access management. There are two possible identity management architectures, one based on a centralized model and the other, on a federated model Centralized model a single operator performs authentication and authorization by owning and controlling all the identity information. Advantages of the Centralized Model: A single operator owns and controls everything, constructing and managing the identity network could be easier than with the federated model. Disadvantage of the Centralized Model The dangerous potential for the single operator becoming a tollgate for all transactions over the Internet. For example, the operator might charge a fee for every transaction you make. You might have to pay a few cents or dollars whenever you perform a transaction on eBay. A single operator could represent a single point of security failure or hacker attack. A single operator can take away the most important business assetthat is, customer identity and profile informationfrom an organization. That results in a serious threat to businesses such as banks and brokerage houses whose success depends on their customer information Federated model both authentication and authorization tasks are distributed among federated communities. The federated model, driven by the Liberty Alliance Project, is designed to correct the centralized model's problems. The goal of the Liberty Alliance Project is to create an

open standard for identity, authentication, and authorization, which will lower ecommerce costs and accelerate organizations' commercial opportunities, while at the same time increasing customer satisfaction. In a Liberty architecture, organizations can maintain their own customer/employee data while sharing identity data with partners based on their business objectives and customer preferences In the federated identity management architecture scheme, three roles could exist Consumer Identity Provider Service Provider Consumer: Consumer can have multiple identity profiles, and you can ask different identity providers to maintain these profiles. For example, you might want your HMO to manage your healthcare profile and your brokerage house to maintain your brokerage profile. In fact, as a consumer, you can pick and choose which identity provider to maintain your profile based on price, credibility, service, and so on. In this model, consumers have a final say in terms of who can access what information. Consumers can be a person, a business, or a software entity. Identity Provider: Identity providers are service providers that specialize in providing authentication services. As the administrating service for authentication, they also maintain and manage identity information. Authentication accomplished by an Identity Provider is honored by all service providers with whom it is affiliated. Identity providers maintain user profile information and can interoperate among themselves as long as they have permission to do so from the profile's owner, the consumer. Service Provider: Service providers are commercial or not-for-profit organizations that offer web-based services. This broad category can include internet portals, retailers, transportation providers, financial institutions, entertainment companies, libraries, universities, and governmental agencies. Service providers can customize their services to each consumer by retrieving relevant identity profiles from the identity providers. In the phase with no federation (separate login for each site), a consumer must log in separately to each site. This phase will then evolve into an environment where multiple identity networks exist. Within a single identity network, single sign-on can be achieved. However, no network-to-network identity propagation is available at this stage. Eventually, these individually constructed and operating identity networks will work together by exchanging their consumers' identity information, thus providing a truly seamless, global-scale identity network, the Liberty Alliance Project's ultimate goal.

A federated identity refers to the amalgamation of the account information in all service providers accessed by one user (personal data, authentication information, buying habits and history, shopping preferences, etc.). The information is administered by the user yet, with the users consent, their privilege to access information is securely shared with their providers of choice. Federated Identity allows users to link identity information between accounts without centrally storing personal information. Also, the user can control when and how their accounts and attributes are linked and shared between domains and service providers, allowing for greater control over their personal data. In practice, this means that users can be authenticated by one company or website and be recognized and delivered personalized content and services in other locations without having to re-authenticate or sign on with a separate username and password. The Liberty Alliance Project The goal of the Liberty Alliance Project is to enable individuals and organizations to easily conduct network transactions while protecting the individuals identity. To accomplish this, the Alliance has established specifications for identity federation that enables: Opt-in account linking where users can choose to federate different service provider accounts Single sign-on where a user can log in, authenticate to one service provider and gain access to other service providers with which they have federated without having to log in again Authentication context where service providers with federated accounts communicate the type and level of authentication that should be used when the user logs in Global log-out where a user logs out of an identity or service provider site and is automatically logged out of all sites that maintain a live session Account linking termination where users can choose to stop their account federation These capabilities can be achieved when commercial or non-commercial organizations join together into a circle of trust based on Liberty-enabled technology and operational agreements. This circle of trust includes service providers (who offer web-based services to users), identity providers (service providers that also maintain and manage identity information), and the users themselves. Once a circle of trust is established between providers, users can choose to federate any or all identities they might have with the service providers that have joined this circle, enabling them to make use of the federated authentication capabilities The summary the goal of Liberty Alliance Project are

To allow individual consumers and businesses to maintain personal information securely. o provide a universal open standard for single sign-on with decentralized authentication and open authorization from multiple providers. To provide an open standard for network identity spanning all network devices. Circle of Trust A Circle of Trust is enabled through federated identity and is defined by the alliance as "a group of service providers that share linked identities and have pertinent business agreements in place regarding how to do business and interact with identities. Once a user has been authenticated by a Circle of Trust identity provider, that individual can be easily recognized and take part in targeted services from other service providers within that Circle of Trust. It should be noted that this concept of trust-based relationships between organizations and their individual or joint customers has existed in the offline business world for years; two common examples would include travel alliances and affiliate business partnerships A circle of trust is a federation of service providers linked together by business relationships. The providers within the circle of trust have operational agreements and sufficient infrastructure in place such that customers can transact business with any or all of these service providers within a secure and apparently seamless environment A trusted provider is a generic term for one of a group of service and identity providers in an Circle Of Trust. Users can transact and communicate with Trusted Providers in a secure environment Specifications Messaging Specifications SOAP WS-Addressing MTOM (Attachments) WS-Enumeration WS-Eventing WS-Transfer SOAP-over-UDP SOAP 1.1 Binding for MTOM 1.0 Reliable Messaging Specifications

WS-ReliableMessaging

Transaction Specifications WS-Coordination WS-AtomicTransaction WS-BusinessActivity

Metadata Specifications WSDL WSDL 1.1 Binding Extension for SOAP 1.2 WS-Policy WS-PolicyAssertions WS-PolicyAttachment WS-Discovery WS-MetadataExchange WS-MTOMPolicy XML Specifications XML Namespaces in XML XML Information Set Management Specifications WS-Management WS-Management Catalog WS-ResourceTransfer Business Process Specifications BPEL4WS Specification Profiles Devices Profile WS-I Basic Profile Security Specification WS-Security XML Signature XML Encryption XML Key Management (XKMS) WS-SecureConversation WS-SecurityPolicy WS-Trust WS-Federation WS-Federation Active Requestor Profile WS-Federation Passive Requestor Profile Web Services Security Kerberos Binding

Web Single Sign-On Interoperability Profile Web Single Sign-On Metadata Exchange Protocol Security Assertion Markup Language (SAML) XACML