WAS v8.5 > Secure applications > Secure web services > Secure web services > Web Services Security concepts > Web Services Security concepts > Web Services Security provides message integrity, confidentiality, and authentication > High-level architecture for Web Services SecuritySecurity authorization models
Provider applications implemented as either servlets or Enterprise JavaBeans (EJBs) can use web services and be protected by Web services security. Java Platform, Enterprise Edition (Java EE) role-based authorization can be used to control access to web service provider applications implemented as either servlets or EJBs. Although security roles for servlet and EJB implementations are configured the same way, access to the services differs by implementation.
For a provider that is implemented as a servlet, the web container performs role-based authorization through HTTP basic authentication.
- A security token is passed in the HTTP header of the SOAP request.
- The web container authenticates the security token, then performs role-based authorization of the user.
- Upon successful user authorization, the web container calls the web services engine with the inbound message.
The following figure illustrates where each step of the role-based authorization process occurs for servlets.
Figure 1. Servlet authorization in Web service security. This figure shows the role-based authorization process for servlet implementations.
For a provider that is implemented as an EJB, the EJB container performs role-based authorization.
- A security token for the user identity is passed in the Security header of the SOAP request.
- Web services security authenticates the token.
- With a caller configuration, Web services security sets the identity of the authenticated token on the current thread.
- When the endpoint is invoked by the web services engine, the EJB container performs role-based authorization on the identity on the current thread.
The following figure illustrates where each step of the role-based authorization process occurs for EJBs.
Figure 2. EJB authorization in Web service security. This figure shows the role-based authorization process for EJB implementations.
When a web service provider is implemented as a servlet, a token that Web services security passes in the Security header of the SOAP request cannot be used for role-based authorization for access to the service.
When a web service provider is implemented as an EJB, a token that Web services security passes in the Security header of the SOAP request can only be used for role-based authorization by the EJB container for access to the service if there is a caller configuration for that token in the active Web services security constraints.
Web service providers implemented as EJBs can also use the web container to perform role-based authorization. To do this, the router servlet shown in figure EJB authorization in Web service security is protected with HTTP Basic Authentication. When this is done, the process proceeds as shown in figure Servlet authorization in Web service security.
When there is a caller configuration in the active Web services security constraints for an inbound token, that token will be set as the runAs identity in the security context on the current thread. The protected provider application itself can make authorization decisions based on that identity. This applies to both servlets and EJBs.
Related concepts:
High-level architecture for Web Services Security
Security model mixture