The goal of this page is to describe in detail how to implement secure REST oriented web service interactions in an environment that is not secure.
Setting
REST interactions implement behind a firewall and within a secure environment are easy, because you don't have to worry about many kinds of attacks because the firewall is blocking people who are not authorized. But when REST web services are implemented on the public internet, in which anyone can attempt to access a service at any time, the security must be implemented in each interaction in order to allow interaction when it should proceed, but not allow it when it should not.
When considering security and protocols, there are always a large number of different ways that things can be implemented. One goal of this effort, and REST in general, is to keep things as simple as possible, but no simpler. Thus at every step will will eschew an elaborate ornamental implementation in favor of a simple and minimalistic implementation. We are not trying to solve exotic special situations, but instead a very straightforward and important general case.
It is hard to design a secure protocol, so it must be done carefully.
Basic Privacy from SSL
Secure Sockets Layer (SSL) is a very commonly deployed mechanism for offering privacy for individual interactions so that information transmitted between a client and a service can not be see by others. SSL is assumed as a minimum capability in all secure interactions. There are many other ways to provide security, but SSL is the most readily available and supported. Because this is commonly available, no other competing options for privacy need to be considered. This means that "https" instead of "http" will be the protocol of all interactions.
OpenID
OpenID provides a way for a user using a browser to authenticate to a site without giving that site their password. This allows one to use the same ID on multiple sites safely.
OpenID is very important for identity coherence in a widely distributed system. If you are working with a lot of servers, or the cloud, then maintaining separate IDs for each server will be impossible. There are many proprietary single sign-on protocols, but OpenID is the most widely available open standard which leverages the specific browser behavior of redirection in order to make logging in transparent to users.
While OpenID is highly recommended, it can not be required. There are two aspects: OpenID as a protocol, and the ability use a single OpenID to a single identity provider at all sites. OpenId has not been accepted by sites that need security, most often because that site will allow only a subset of all identity providers. Many sites contain sensitive information and can not trust an external identity provider.
That status of OpenID is that it should be encouraged, but we can not assume that a particular OpenID will be valid at all sites.
OAuth
OAuth is a way for a user to permit a program to access a service. It is a given that the user has access to the service. And it is a given that the user has access to the program that will be doing the calling. Given this situation, the client program can initiate and exchange information initially, and the user can validate that exchange, in such a way that later the client program will be allowed to call the service on that users behalf.
Last edited by Keith Swenson 12/13/2008(Effective date 12/13/2008)
You are viewing a static copy of
a project that was originally a wiki.
These pages can not be modified
at this location even though the page
may appear incomplete.
This copy was generated on
01/29/2012
and this project information has not been
changed since 12/13/2008.
REST Security
The goal of this page is to describe in detail how to implement secure REST oriented web service interactions in an environment that is not secure.
Setting
REST interactions implement behind a firewall and within a secure environment are easy, because you don't have to worry about many kinds of attacks because the firewall is blocking people who are not authorized. But when REST web services are implemented on the public internet, in which anyone can attempt to access a service at any time, the security must be implemented in each interaction in order to allow interaction when it should proceed, but not allow it when it should not.
When considering security and protocols, there are always a large number of different ways that things can be implemented. One goal of this effort, and REST in general, is to keep things as simple as possible, but no simpler. Thus at every step will will eschew an elaborate ornamental implementation in favor of a simple and minimalistic implementation. We are not trying to solve exotic special situations, but instead a very straightforward and important general case.
It is hard to design a secure protocol, so it must be done carefully.
Basic Privacy from SSL
Secure Sockets Layer (SSL) is a very commonly deployed mechanism for offering privacy for individual interactions so that information transmitted between a client and a service can not be see by others. SSL is assumed as a minimum capability in all secure interactions. There are many other ways to provide security, but SSL is the most readily available and supported. Because this is commonly available, no other competing options for privacy need to be considered. This means that "https" instead of "http" will be the protocol of all interactions.
OpenID
OpenID provides a way for a user using a browser to authenticate to a site without giving that site their password. This allows one to use the same ID on multiple sites safely.
OpenID is very important for identity coherence in a widely distributed system. If you are working with a lot of servers, or the cloud, then maintaining separate IDs for each server will be impossible. There are many proprietary single sign-on protocols, but OpenID is the most widely available open standard which leverages the specific browser behavior of redirection in order to make logging in transparent to users.
While OpenID is highly recommended, it can not be required. There are two aspects: OpenID as a protocol, and the ability use a single OpenID to a single identity provider at all sites. OpenId has not been accepted by sites that need security, most often because that site will allow only a subset of all identity providers. Many sites contain sensitive information and can not trust an external identity provider.
That status of OpenID is that it should be encouraged, but we can not assume that a particular OpenID will be valid at all sites.
OAuth
OAuth is a way for a user to permit a program to access a service. It is a given that the user has access to the service. And it is a given that the user has access to the program that will be doing the calling. Given this situation, the client program can initiate and exchange information initially, and the user can validate that exchange, in such a way that later the client program will be allowed to call the service on that users behalf.