Web Services Authentication Security Patterns

In the development of secure applications, patterns are useful in the design of security functionality. Mature security products or frameworks are usually employed to implement such functionality. One of the most exciting developments in software engineering is the
emergence of design patterns as an approach to capturing, reusing, and
teaching software design expertise.Yet, without a deeper comprehension of these products, the implementation of security patterns is difficult, as a non-guided implementation leads to non-deterministic results. Security engineering aims for a consecutive secure software development by introducing methods, tools, and activities into a software development process.

There are two main patterns (when consider architecture) for authentication. Both pattern focus on the relationships that exist between a client and service participating in a Web
service interaction.
1.Direct authentication
The Web service acts as an authentication service to validate credentials from the client. The credentials, which include proof-of-possession that is based on shared secrets, are verified against an identity store.
2.Brokered authentication
The Web service validates the credentials presented by the client, without the need for a direct relationship between the two parties. An authentication broker that both parties trust independently issues a security token to the client. The client can then present credentials, including the security token, to the Web service.

Considering design Brokered authentication can be subcategorize…

Brokered Authentication: Kerberos
Use the Kerberos protocol to broker authentication between clients and Web services.

The Web Server has to hand-shake with browser to obtain kerberos token. The token can be validated against keytab file  or connecting through Active Directory.
The below diagram explains how the handshake happens between browser and webserver to obtain kerberos token for authentication.

Brokered Authentication: X.509 PKI
Use brokered authentication with X.509 certificates issued by a certificate authority (CA) in a public key infrastructure (PKI) to verify the credentials presented by the requesting application.

The X.509, PKI X.509 and Public Key Cryptography Standards (PKCS) are the building blocks a PKI system that defines the standard formats for certificates and their use.A typical X.509 standard digital certificate has following format,

Brokered Authentication: STS
Use brokered authentication with a security token issued by a Security Token Service (STS). The STS is trusted by both the client and the Web service to provide interoperable security tokens.
The Security Token Service, based on WS-Trust specification addresses the token translation challenge where a web service or client can translate one token to another token. Security Token Service should be part of Web Services Security Architecture and it acts as a broker in translating one token to another token format. Whether or not you have a WS-Security product (which may or may not have STS), your Security Architecture should consider STS as a key Architecture building block.

Client Applications + STS + WS-Security Gateway == SOAP Message with appropriate authentication token.

With the above architecture, you actually delegate the token translation and certain cryptographic key management to a central service. STS can be extended to include any number of input and output token formats without affecting the client applications and removing redundant code across various client applications.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s