Applying Enterprise Security Patterns with an Internal as well as Cloud Deployment

  • By Amila Jayasekara
  • 30 Aug, 2013

This document discusses a few security patterns that can be applied to an enterprise with an internal deployment as well as a cloud deployment. In addition, it discusses a few patterns that can be used to secure communication between services.

2 Background

2.1 Introduction

In an enterprise, the SOA platform can be deployed in 2 different ways. They are;

  1. As an internal deployment
  2. As a cloud deployment

Usually, enterprises will have a hybrid deployment where they have some services within the boundaries of the enterprise network and some services in the cloud.

Moreover, we can categorize services as follows:

  1. Proxy Services - These services reside in the service integration layer (at ESB)
  2. Business Services - End users access these services to achieve some business functionality
  3. Mashup Services - Mashups are responsible for aggregating data from different web services and presenting useful data to “Business Services”
  4. Data Services - Data services directly communicate with a data storage such as a file system, database, and present required data as a service

Usually “Data Services” that need to access internal resources such as “Active Directory” (AD OR LDAP) and Database are deployed internally. The “Business Services” may reside within the organization's network or may stay in the cloud.

If we need to expose any of those services in cloud, we could use “Cloud Services Gateway” (CSG).

In an enterprise scenario, services will also communicate with each other. Thus, service to service communication should also be trusted. In addition, a service may not trust another service without having sufficient proof.

2.2 Service Architecture

Architecturally, services can be organized into layers.

Figure 2.0

Figure 2.0 gives a rough idea on how services are organized within an enterprise. All services that directly interact with data are categorized as data services. Then the output of data services is mashup/integrated, so that they can be directly consumed by “Business Services”. This integration is carried out in the “Data Mashup” layer. Business services are services that perform actual business activities.

Even in cloud deployed services, the below “Mashup Layer” has to be deployed within the enterprise. Thus, those services will be exposed to cloud through CSG (Cloud Services Gateway). In addition, services hosted in “Identity Server” will also remain within the enterprise because those services need to access “Active Directory”, “Database” etc. 

3.0 Some Requirements

  1. User credentials are stored in a “LDAP Server” or in a Database. Thus, users must be authenticated against credentials stored in LDAP or Database.
  2. An authenticated user should not be able to access any service. A user must be authorized before accessing a service.
  3. Deployed “Business Service” code is also not trusted. A “Business Service” might call another “Business Service” before sending final results to clients. Hence, the service to service call must be controlled using an authorization mechanism.
  4. The platform should support a single sign on.

4.0 Suggested Patterns

In subsequent sections we will be using the following notations in the diagrams.

Figure 4.0

4.1 Pattern 1 – “User name token over HTTPS” for client-proxy and “X509 Symmetric Binding” for service-service

We need to authenticate users against “LDAP”. Therefore, we select “Username Token” to authenticate clients against “LDAP”. In order to preserve confidentiality of the client’s password details, we will be using a username token over an HTTPS channel. Users are authorized using their username.

4.1.1 Client – Proxy communication

Figure 4.1

According to Figure 4.1, the client sends a message with the username token over an HTTPS channel. Then the proxy evaluates the authenticity of the incoming user. If the user is authenticated, the proxy will check whether the user has sufficient privileges to access the service. For this we can use XACML authorization.

Communication between proxy’s endpoint and service is secured using message level security. In this case, we use certificate (X509-Symmetric binding) based encryption and signing. In order to complete security implementation, we need to import S1’s public key into E1’s trust store.

4.1.2 Service-Service communication

Figure 4.2

According to Figure 4.2, services will directly interact with each other. A service does not need to go through ESB as it adds another hop. Thus, service-service communication is secured using X-509, symmetric binding (mashup services are not shown in Figure 4.2 for brevity).

According to Figure 4.2, S1 can talk to S2, but S3 cannot access S2. S1 is allowed to access S2, because S2’s public key is installed in S1’s trust store. But S3 does not have S2’s public key; therefore, S3 cannot communicate with S2. In other words, access controls among services are controlled by public certificate deployment. At the AS (Application Server) level, each service will maintain its own trust store. But at an ESB level, services do not need to maintain trust store per proxy.

In some cases enterprises prefer to have all their traffic routed through ESB. Therefore, we can slightly modify the above pattern and have a pattern as depicted in Figure 4.3

Figure 4.3

According to Figure 4.3, S1 will contact S2 through a proxy service (P12). The communication between S1 and S2 is secured using X509 Symmetric Binding. P12 is a pass through proxy service. Thus, whenever we need to enable communication between 2 services, we need to add a new proxy service. This methodology adds an additional communication overhead as it needs to go through a proxy service to communicate to service S2 (compared to the methodology described in Figure 4.2). But this methodology preserves consistency.

4.1.3 Cloud deployment

Figure 4.4

There are services that need access to internal resources such as Databases and “LDAP”. Such services cannot be deployed in the cloud. Still, we can expose these services to cloud, with the help of CSG (Cloud Services Gateway). We can use CSG to publish internal service in the cloud. Publishing will create a proxy service in the cloud environment. Hence, a secure channel is created between the cloud ESB and internal proxy service. This behavior is depicted in Figure 4.4. The cloud proxy is responsible for routing all traffic to internal service through the secure channel.

According to Figure 4.4, internal “Mashup Services” are exposed to cloud using the CSG. A complete service structure in internal deployment is not depicted in Figure 4.4.

The requests coming to the cloud proxies need to be authenticated against the internal “LDAP”. Requests also require to be authorized against XACML policies. To accomplish this requirement, we introduce a new service called “AuthService”. “AuthService” is secured using “Username Token over HTTPS” policy. Thus, “AuthService” is exposed to cloud through CSG (AuthService-Cloud).

The cloud proxy service (P1) only accepts HTTPS traffic (but P1 will publish a WSDL with a username token over HTTPS policy);  P1 will call the “AuthService” through the published “AuthService-Cloud” proxy. “AuthService” will authenticate the user. In addition, “AuthService” will call “Identity Server” to evaluate the XACML policy for the given username. If the user is not successfully authenticated or authorized, “AuthService” will return an SOAP fault with a description of the error. P1 will not allow the user’s request if “AuthService” returns a SOAP fault.

4.1.4 Advantage and disadvantages

Advantages

  1. ”Username Token” over HTTPS channel is a fairly simple security policy to implement.
  2. With this pattern we have a uniform security mechanism for both cloud deployment and internal deployment – we do not need to change the client code when switching from internal services to cloud services.
  3. Easy to test – tools such as SoapUI have support for “Username Token”. Therefore, testing will be easy with this pattern.

Disadvantages

  1. We may able to maintain a single truststore at ESB level. But at AS, we need to maintain a key store for each service in AS. Otherwise, we cannot control service to service calls.
  2. If a service needs to call another service, the public key of the target service needs to be imported into the calling service’ truststore. Thus, if we want to restrict a service calling another service, we need to remove the second service’s public key from the first service’ truststore. This approach might be hard to maintain in a long-running system. Moreover, it is difficult to figure which services can communicate with other services by looking at the system.
  3. In the context of asymmetric cryptography, public key certificates are not treated as confidential as their private keys. A person who has admin rights to the management console may be able to import the public key of another service to a service he deployed and communicate with a non-authorized service.
  4. This pattern does not provide non-repudiation during a service to service call and during an endpoint to service call.
  5. If we use the methodology depicted in Figure 4.3, we have to define a new proxy service each time we need service-service communication.
  6. No single sign on ability.

4.2 Pattern 2 – “WS-Trust with SSO” for client-proxy and “X509 Symmetric Binding” for service-service

Pattern 2 is a slight variation of pattern 1. In pattern 2, we use a “Security Token Service” (STS).

4.2.1 Client – Proxy communication

Figure 4.5

In this case, the client does not present its username, password directly to the proxy service. Instead, the user first sends his/her username and password details to a security token service running within the “Identity Server”. Then, the user obtains a security token from STS and uses that token to encrypt/sign message to the proxy service. When implementing this pattern, we need to copy STS’s public key to ESB.

The communication between proxy service and the AS service is same as in pattern 1.

4.2.2 Service-Service communication

Service to service communication is same as in pattern 1 (described in section 4.1.2).

4.2.3 Cloud deployment

An enterprise user may access the cloud proxy from outside the organization's network. In that case, we need to expose STS Service to cloud. Only then users will be able obtain a valid token (also STS needs to access a user store).

Figure 4.6

According to Figure 4.6, a client sitting outside the enterprise environment will first talk to the STS proxy in cloud. STS proxy (STS-Cloud) will then direct traffic to STS running inside the organization's network through a secure channel. STS within the organization will validate client credentials and issue a valid token. Then the client can use an issued token to secure a request message and send it to the proxy service (P1) running within cloud. P1 will first check whether the user is authorized to access the service. “AuthorizeService” can be an “Entitlement Service” running inside “Identity Server” or it can be an intermediate service that sits between P1 and “Identity Server” running within the organization's network.

4.2.4 Advantage and disadvantages

Advantages

  1. This pattern has single sign on ability.
  2. With this pattern we have a uniform security mechanism for both cloud deployment and internal deployment – we do not need to change the client code when switching from internal services to cloud services.
  3. Easy to test – tools such as SoapUI have support for “Username Token” and SAML token. Therefore, testing will be easy with this pattern.

Disadvantages

  1. We may be able to maintain a single truststore at the ESB level. But at AS (Application Server), we need to maintain a keystore for each service in AS. Otherwise we cannot control service to service calls.
  2. If a service needs to call another service, the target service’s public key needs to be imported into calling a service’s truststore. Thus, if we want to restrict a service calling another service, we need to remove the second service’s public key from the first service’s truststore. This approach might be hard to be maintained in a long running system.
  3. In the context of asymmetric cryptography, public key certificates are not treated as confidential as their private keys. A person who has admin rights to the management console may able to import the public key of another service to a service he deployed and communicate with a non-authorized service.
  4. This pattern does not provide non-repudiation during a service to service call and during an endpoint to service call.

4.3 Pattern 3 – “User name token over HTTPS” for client-proxy and “User name token over HTTPS” for service-service

4.3.1 Client – Proxy communication

Client-Proxy communication behavior is the same as described in Section 4.1.1.

4.3.2 Service-Service communication

In this particular pattern we provide names to services, i.e. we register a name in “LDAP” and assign that name to a service. When a service calls another service, it has to provide the username registered in "LDAP".

Figure 4.7

In this pattern, proxy services do not differentiate between service-service requests and user-service requests. In other words, business services and users are authenticated/authorized in an identical manner.

As mentioned above, we register services with the “LDAP”. E.g. S1 is registered in LDAP with the name “Service1”. When S1 needs to access S2, S1 calls proxy service P2 with the name “Service1”. Then “Service1” is authenticated at P2 and directed to XACML engine for authorization. If there is an XACML policy to allow “Service1” to access S2, P2 will proceed. If not, P2 will reject the request.

In this pattern service-service call is controlled at the authorization stage. To control service-service communication we use XACML policy. In addition, we can group the services and assign roles to different services in “Identity Server”. Then we can control service-service communication based on service roles (groups).

4.3.3 Cloud deployment

Cloud deployment with this pattern is pretty much the same as described in 4.1.3. During service-service communication in the cloud, proxy service (P2 in Figure 4.7) will not talk to the XACML engine (as depicted in Figure 4.7); instead it will communicate with a CSG published authorized service.

4.3.4 Advantage and disadvantages

Advantages

  1. Username token over the HTTPS channel is a fairly simple security policy to implement.
  2. With this pattern we have a uniform security mechanism for both cloud deployment and internal deployment – we do not need to change the client code when switching from internal services to cloud services.
  3. Easy to test - tools such as SoapUI have support for “Username Token”. Therefore, testing will be easy with this pattern.
  4. With this pattern, we can categorize services into groups and assign roles to them in “IS”. Then we can authorize service-service communication using RBAC (Role Based Access Control).
  5. When compared with Pattern 1 and Pattern 2, we do not need to maintain a trust store for each service. Also, we do not need to import the certificate of another service when we need to enable communication between services.

Disadvantages

  1. We need to assign names to services and define them in “LDAP”. Also, we need to assign service names to roles if we are using RBAC authorization for service-service communication.
  2. No single sign on ability.

4.4 Pattern 4 – “WS-Trust with SSO” for client-proxy and “User name token over HTTPS” for service-service

4.4.1 Client – Proxy communication

Client-Proxy communication behavior is similar to Section 4.2.1.

4.4.2 Service-Service communication

Service-service communication is quite similar to service-service communication explained in 4.2.1. But we need to add an additional proxy service each time when the service needs to talk to another service.

Figure 4.8

According to Figure 4.8, when S1 needs to communicate with S2 we have to create a new proxy (P2). S1 cannot re-use P3 as it did in Figure 4.7 because P2 and P3 are using 2 different security policies. In this case, we need to define service names in “LDAP” for each service and add those service names to roles in “Identity Server”.

P2 will first authenticate an incoming “service name”, password credentials and then direct a request to “Entitlement Service”. “Entitlement Service” will check whether the service is authorized to access service S2.

4.4.3 Cloud deployment

Cloud deployment with this pattern is pretty much the same as described in 4.2.3. During service-service communication in the cloud, proxy service (P2 in Figure 4.8) will not talk to XACML engine (as depicted in Figure 4.7), instead it will communicate with a CSG published authorize service.

4.4.4 Advantage and disadvantages

Advantages

  1. This pattern provides “Single Sign On” (SSO) capability.
  2. With this pattern we have a uniform security mechanism for both cloud deployment and internal deployment – we do not need to change the client code when switching from internal services to cloud services.
  3. Easy to test – tools such as SoapUI have support for “Username Token” and SAML token. Therefore testing will be easy with this pattern.
  4. With this pattern we can categorize services into groups and assign roles to them in “IS”. Then we can authorize service-service communication using RBAC (Role Based Access Control).
  5. When compared with Pattern 1 and Pattern 2 we do not need to maintain trust store for each service. Also we do not need to import certificate of another service when we need to enable communication between services.

Disadvantages

  1. We need to assign names to services and define them in “LDAP”. Also, we need to assign “Service Names” to roles if we use RBAC authorization for service-service communication.
  2. For each service-service communication we need to add an additional proxy service to ESB. This is because we are using 2 different security mechanisms to secure communication between client-service and service-service.

4.5 Pattern 5 – “WS-Trust with SSO” for client-proxy and “WS-Trust with SSO” for service-service

4.5.1 Client – Proxy communication

Client-Proxy communication behavior is equivalent to description in Section 4.2.1.

4.5.2 Service-Service communication

Figure 4.9

Figure 4.9, describes, service-service communication behavior in this pattern. If S1 wants to talk to S2, S1 needs to first communicate to STS and retrieve a valid token. In this pattern as well we assign names to services and register them in “LDAP”. S1 needs to get a token from STS by providing S1’s user name and password. Then S1 can use retrieved token sign and encrypt messages from S1 to P2. Thus when P2 receives a message, it will authorize user with a XACML policy. If user is authorized, P2 will allow the call to propagate to S2.

In this pattern we need to deploy P2’s public key in STS’s keystore. In other words, if a service needs to communicate with another service, the intermediate proxy service’ public key certificated needs to be deployed in STS trust store.

4.5.3 Cloud deployment

Cloud deployment with this pattern is pretty much same as described in 4.2.3. During service-service communication in the cloud, proxy service (P2 in Figure 4.8) will not talk to XACML engine (as depicted in Figure 4.7) nor STS, instead it will communicate with a CSG published authorized service and a CSG published STS service.

4.5.4 Advantage and disadvantages

Advantages

  1. This pattern provides “Single sign on” (SSO) capability.
  2. With this pattern we have a uniform security mechanism for both cloud deployment and internal deployment. – We do not need to change client code when switching from internal services to cloud services.
  3. Easy to test. – Tools such as SoapUI have support for “Username Token” and SAML token. Therefore testing will be easy with this pattern.
  4. With this pattern we can categorize services into groups and assign roles to them in “IS”. Then we can authorize service-service communication using RBAC (Role Based Access Control).
  5. When compared with Pattern 1 and Pattern 2, we do not need to maintain trust store for each service. Also, we do not need to import certificate of another service when we need to enable communication between services.

Disadvantages

  1. We need assign names to services and define them in “LDAP”. Also we need to assign users to roles if we are using RBAC authorization for service-service communication.
  2. We need to import public key certificate of each proxy service that act as an intermediate party during a service-service communication, to the STS trust store.

4.6 Pattern 6 – “Kerberos Authentication” for client-proxy and “X509 Symmetric Binding” for service-service

4.6.1 Client – Proxy communication

In this pattern we will be authenticating users using Kerberos protocol. User first needs to connect to a KDC (Key Distribution Center) and need to retrieve a valid token. Then user can use the retrieved Kerberos token to sign and encrypt messages exchanged between the server and the client.

Figure 4.10

As depicted in Figure 4.10, client first needs to retrieve a Kerberos token from KDC and then client uses retrieved token to sign message from client to the proxy (P1). Prior to the communication we need to setup a “Service Principal” for ESB in KDC.

4.6.2 Service-Service communication

Service to service communication is same as in pattern 1. (Described in section 4.1.2)

4.6.3 Cloud deployment

We cannot implement a proper cloud deployment with this security pattern; because both service and client must be within organization network in-order to access “Key Distribution Center” (KDC).

4.6.4 Cloud deployment – Accessing outside organization network

If this pattern is implemented, users still need to access services in cloud, outside organization network; we can use a different security mechanism.

The suggested mechanism is to use WS-Trust. The Figure 4.12 describes the mechanism.

Figure 4.11

According to Figure 4.11 we are using the STS in cloud. Thus to communicate with STS we are using Asymmetric Binding based on X509 mechanism. This implies that user needs to have a key pair to communicate with STS and user’s public key must be trusted by STS. Also, client needs to have STS public key, to decrypt incoming token. If client provides legitimate public key certificate, he/she will be able to retrieve a valid token from cloud STS. Then client will be able to communicate with proxy (p1) using the retrieved token. In addition to token, client has to provide the user name to authorize him/her to access a service.

4.6.5 Advantage & Disadvantages

Advantages

  1. This pattern has single sign on ability.
  2. Since we are using Windows authentication in this pattern, users does not need to enter user name or password (When using windows logins).

Disadvantages

  1. This pattern cannot be used when users needs to access cloud services outside organization network. For outside users we have to use a different security mechanism.
  2. We are using Kerberos token profile for STS communication. Test tools such as SoapUI does not have support for Kerberos token profile. Therefore testing will be a challenge with this pattern.
  3. We may be able to maintain a single truststore at ESB level. But at AS we need to maintain keystore for each service in AS. Otherwise we cannot control service to service calls.
  4. If service needs to call another service, the target service’ public key needs to be imported into calling service’ truststore. Thus if we want to restrict service calling to another service, we need to remove second service’ public key from second service’ truststore. This approach might be hard to maintain in a long running system.
  5. In the context of asymmetric cryptography, public key certificates are not treated as confidential as their private keys. A person who has admin rights to the management console may able to import public key of another service to a service he deployed and communicate with a non-authorized service.
  6. This pattern does not provide non-repudiation during a service to service call and during an endpoint to service call.

4.7 Pattern 7 – “WS-Trust with SSO” for client-proxy (With Kerberos Authentication for STS) and “X509 Symmetric Binding” for service-service

4.7.1 Client – Proxy communication

Client-proxy communication of this pattern is a slight variation of 4.2.1. In 4.2.1 we authenticated user to STS using username and password. But in this pattern user is authenticated to STS using a Kerberos Token. In other words STS is secured using Kerberos Token profile. As described in section 2, most of the organization users work in Windows environment. Therefore they prefer Windows authentication to login to services. We can use windows credentials to retrieve a Kerberos token from “LDAP” (AD). Then user does not need to enter username and password, rather when they logged into their machines, they will get authenticated to services.

Figure 4.12

As depicted in Figure 4.12 user will first retrieve a Kerberos token from “KDC”. Then user will use retrieved Kerberos token to secure message communication between STS and himself. If Kerberos token is valid, STS will issue a WS-Trust token to the user. Then user can use the WS-Trust token to secure communication between himself and proxy service.

When implementing this pattern we need to define a “Service Principal” in KDC (Key Distribution Center) and assign that service principal to STS.

4.7.2 Service-Service communication

Service to service communication is same as in pattern 1. (Described in section 4.1.2)

4.7.3 Cloud deployment

According to Figure 4.12, this pattern needs to communicate, directly with KDC to establish security context. But as per organization’s pre-conditions we cannot expose KDC, outside of organization network. This restricts the access of cloud services only to users within the organization. Figure 4.13 depicts this behavior.

Figure 4.13

In this pattern we do not need to publish STS to cloud for 2 reasons;

  1. STS does not need to access a user store; because STS is secured using Kerberos Token Profile.
  2. Users outside organization network cannot access cloud web services; because client needs to get a Kerberos token from KDC and KDC is not accessible from outside the organization network.

4.7.4 Cloud deployment – Accessing outside organization network

If this pattern is implemented and still users need to access services in cloud, outside organization network, we can use a security mechanism described in 4.6.4.

4.7.5 Advantage & Disadvantages

Advantages

  1. This pattern has single sign on ability.
  2. Since we are using Windows authentication in this pattern, users does not need to enter username or password (When used windows logins).

Disadvantages

  1. This pattern cannot be used when users needs to access cloud services outside organization network. For outside users we have to use a different security mechanism.
  2. The initial security context setup will be slow. With this pattern first, user need to contact “KDC” to retrieve Kerberos token. Then user needs to initialize SSL channel with STS (If SSL is used in STS communication). Due to these actions initial security context setup will take some time.
  3. We are using Kerberos token profile for STS communication. Test tools such as SoapUI does not have support for Kerberos token profile. Therefore testing will be challenged with this pattern.
  4. We’ll be able to maintain a single truststore at ESB level. But at AS we need to maintain keystore for each service in AS. Otherwise we cannot control service to service calls.
  5. If service needs to call another service, the target service’ public key needs to be imported into calling service’ truststore. Thus if we want to restrict service calling another service, we need to remove second service’ public key from second service’ truststore. This approach might be hard to maintain in a long running system.
  6. In the context of asymmetric cryptography, public key certificates are not treated as confidential as their private keys. A person who has admin rights to the management console may able to import public key of another service to a service he deployed and communicate with a non-authorized service.
  7. This pattern does not provide non-repudiation during a service to service call and during an endpoint to service call.

5 Summary

Above we discussed few security patterns applicable to an enterprise. Also, we discussed how we can authenticate and implement other security features to cloud based services. Depending upon advantages and disadvantages of each pattern we need to select the best matching pattern for a particular use case.

Author:

Thejaka Amila Jayasekara

Research Assistant at Indiana University Bloomington

About Author

  • Amila Jayasekara
  • Research Assistant
  • Indiana University Bloomington