Web Services standard security implementation overview
Before Web Services can be used, security issues need to be addressed and security requirements such as authentication, access control, non-repudiation, data integrity, and privacy must be tackled by the underlying security technology.
Authentication: ensure the business partner is who he pretends to be
Access Control: check the partner is allowed to call this action on those data
Non-repudiation: the partner cannot withdraw his position after the order has been sent
Data Integrity: data received cannot have been modified by a third party
Privacy: no unauthorized person can see secure data
Auditing: any action on any data can be trace back
As Web Services are meant to be consumed by systems and not directly by users, authentication can be performed by either: providing the credentials of the user currently logged in the application, or to connect as a machine without providing user credential.
1. If providing the logged in user credentials: the system authenticates the user and provides the user credentials to the back-end Web Service. All calls to the Web Service are then made in the name of the user and access is allowed or denied depending on the logged in user rights.
Figure 1 - Delegating authentication to the Web Service provider
2. If connecting as a machine: the front-end system is responsible to authenticate the user. It calls the underlying Web Service without providing the logged-in user credential.
Thus security is insured by authenticating the calling machine. The machine can authenticate itself with a certificate or by providing a generic username and password. Although using a certificate is more secure, a username and password is commonly used, in the same way as an application accesses a database with encrypted security credentials.
Figure 2 - Authenticate to the Web Service provider as a machine
From the point of view of the Web Service, whether the authentication credentials come from an end-user or a machine does not make much difference. In the first case, the machine provides the user authentication credential provided to it, in the other case the machine provides its own authentication credential.
From there, authentication strategies are:
- Provide the username and password of the user through HTTP header. This is the same process as when a user authenticate to a web site
- Use WS-Security standard feature. WS-Security is part of the WS-* specifications proposed by OASIS which is the organization that defines Web Service standards. It describes a set of SOAP header extensions and allow authentication with:
- Kerberos tickets: a standard and widely use authentication protocol published by the MIT
- Username and/or password Token Profile: similar to sending username and password with http header, but this time using WS-Security header, thus allowing an end-point to end-point authentication as opposed to point to point authentication as for HTTP header.
- SAML Token Profile: a specification that tries to solve Single Sign-On issues for Web Services
- PKI certificate Token Profile: The most common authentication practice for Web Services. It is also the one use for credit card transaction over the internet. It consist of using a Public Key Infrastructure certificates which works as described in the diagram above:
Figure 3 - PKI certificate usage
User repository:
Then, the authentication itself must be performed against a user repository. The most standard user repositories are LDAP like directory tree such as Microsoft Active Directory. It allows administrators to simply manage a list of users and is a standard for any tool that needs to perform authentication.
Access control is to use to define the rights of the users concerning all actions and data of the application. Typically it defines:
- Roles: like “Administrator”, “Clerk”, etc.
- Actions: like “Create New Employee”, “Read Employee”, “Change Employee Salary”
- Roles to Actions mapping: like
- “Administrators” can “Create New Employee” and “Change Employee Salary”
- “Clerk” can “Read Employee”
However, access control can be defined according to action or can be defined according to action and type of data. For example, the user “China Manager” can do the action “Modify Employee” only on the data “China Employee”. On the data “India Employee”, he can only do the action “Read Employee”.
The implementation of the first type of Access Control List, only according to action, is done by creating User Groups in the user repository: Users are positioned into User Group and all actions are associated to a User Group. So if the user does not belong to the associated User Group it cannot perform the action independently of the data manipulated.
The implementation of the second type of Access Control List can either be done by creating as many actions as there are types of data. It means that an action “Modify Geneva Employee” will be created and this action can only manipulate “Geneva employee”. This present the drawback of having to create a full set of action each time a new “region” is created.
Or the data can be flagged to belong to one “region” and all Users have a role according to a region. He could then only do a certain type of action on the data from a region.
This type of Access Control List implies that the data can be associated to a region, and that the user can also be positioned against this region. However Users and Access Control List usually resides in the user repository and data resides in the database, thus the concept of region need to exist and be consistent in both the database and the user repository.
Then the options are:
- Regions need to be maintained between user repository and database. This present the risk of desynchronized data and maintenance needs to be setup either automatically or manually.
- Database is used as User Repository. This implies that the user list is kept in a proprietary format, thus all tools that are used with LDAP protocol in mind cannot be used or need adapter.
- A tool is used to synchronize or consolidate the data between the database and the repository. It can be done either through synchronization or through virtualization
- Synchronization means that processes will regularly fetch the data from multiple user repositories (LDAP directory, Active Directory, Proprietary Database or any other format). Those processes will bring back the data to a single user repository, often an LDAP server. Thus only one repository contains all the data concerning the Users, their Access Control List and the “region” they belong to.
- Virtualization means that a virtual directory is set in place and when called, it will actually launch processes to go and fetch the information from multiple repositories. It will then present the information to the requester as if it came from a single repository. With this solution, no information is duplicated unlike with solution above.
Access control standardization with XACML:
XACML stands for Extensible Access Control Markup Language, and its primary goal is to standardize access control language in XML syntax. A standard access control language results in lower costs because there is no need to develop an application-specific access control language or write the access control policy in multiple languages. Plus, system administrators need to understand only one language. With XACML, it is also possible to compose access control policies from the ones created by different parties.
Non-repudiation is the concept of ensuring that a party in a dispute cannot repudiate, or refute the validity of a statement or contract. So in case of dispute, a Trusted Third Party is necessary to guarantee that the refuting party did actually commit to the agreement.
On the digital side, the Trusted Third Party is often a Certificate Authority such as VeriSign or SwissSign. They provide Public Key Infrastructure Certificate to both party and, in case of dispute, can be requested to validate the signatures on the signed documents.
Certificate Authority also create, distribute and revoke certificate so that both party involve in a transaction are certain that the Public Key Infrastructure Certificates used for the transaction are valid before the transaction starts.
Figure 4 - Non-repudiation with PKI certificate
An alternative to the Public Key Infrastructure model is a Web of Trust which is a concept used by Open Source cryptography model like PGP, GnuPG and other OpenPGP compatible system.
In this model, digital signature and business agreement are exchanged in a face to face meeting before any transaction starts.
The Web of Trust presents the advantage to be unaffected by third party company failure
Data integrity, in terms of network security, is the insurance that no one can have modified the message between the sending and the reception. This is typically to prevent a “man in the middle” (MITM) attack where someone relays messages between communicators, making them believe that they are talking directly to each other over a private connection when in fact the entire conversation is controlled by the attacker.
Measures taken to ensure integrity and prevent MITM attack include, controlling the physical environment of networked terminals and servers, restricting access to data, and maintaining rigorous authentication and encryption practices.
Usage of Public Key Infrastructure certificates are commonly used to insure Data Integrity. It is quite all the time used in conjunction with encryption even though data integrity does not need Encryption as the aim is only to insure that the data has not been modified.
The typical usage to PKI certificate for Data Integrity and Data Privacy is explained on the diagram below:
Figure 5 - Data integrity and data privacy using PKI certificates
The key points from a Data Integrity point-of-view are step 1 - Bob sign the message, and step 8 - Alice verifies the hash of Bob’s signature.
A hash is like a digital "fingerprint" that uniquely identity a document. By recomposing the hash of the document, Alice cans checks:
- It is Bob that has signed the message with his private key (or someone that has stolen Bob private key, which is normally impossible)
- The hash reproduce by Alice is similar to the hash signed by Bob. If someone has changed the document, Alice could detect the modification by making a hash out of the document and check the difference.
In a way, Data integrity can also be insured through encryption. By making sure that nobody else could read the message, encryption insure that nobody can modify it.
Privacy is insured through a secure network (a VPN or an intranet) or through encryption. The 2 main encryption technologies for Web Services are:
- SSL/TLS (Secure Socket Layer/Transport Level Security) for point-to-point security. Similar to HTTPS, SSL is commonly use for credit card transaction over the internet and present a level of security hat is sufficient for most transaction. However, Web service application topologies include all sorts of devices, PCs, proxies, demilitarized zones, gateways, etc. Consequently, many intermediaries come between two communicating parties. SSL/TLS may secure the path between any two, but not from one end to the other.
Furthermore, SSL/TLS encrypt the whole message and does not discern confidential to public data.
- XML encryption allows encrypting only a part of the XML message, thus it allows end-point to end-point cryptography and allow better performance as it encrypts only part of the message.
Both SSL/TLS and XML encryption can use PKI certificate has explained on diagram Figure 5 - Data integrity and data privacy using PKI certificates. Then the public key of the certificate is used for encrypting the message and only the private key can decrypt it.
Auditing is to insure all actions that have been made were authorized and no abuse has been performed. Application log strategy needs to be defined to enabler log analyzer tool to search through the log file. This is usually automatically defined when choosing the tools.
