Security Patterns : Single Sign On across Web Applications and Web Services

The requirement is to have single sign on across different web applications - once the user is  authenticated he should be able to access all the web applications with no further authentication [by him self]. Also, the web applications need to access a set of back-end services with the logged in user's access rights and the back-end services will authorize the user [end-user] based on different claims, like role.

1. User hits the link to the WebApp

2. WebApp finds out user is not authenticated and redirects to the SAML2 IdP.

3. SAML2 Idp checks whether the user has an authenticated session - if not will prompt for credentials, once authenticated there ,user will be redirected back to WebApp with a SAML token, with the set of claims requested by the WebApp

4. Now, the WebApp needs to access a back-end web service with the logged in user's access rights. WebApp passes the SAML token to the PEP based on WS-Trust and authenticates it self [WebApp] to the PEP via trusted-sub-system pattern.

5. PEP will call XACML PDP to authorize the user, based on the claims provided in the SAML token.

6. XACML PDP returns back the decision to the PEP.

7. If it's a 'Permit' - PEP will let the user access the back-end web service.

Cross Domain Authentication Patterns - Kerberos with STS

Business Requirements : 1. Users from domain A - need to access a service in domain B 2. Not all the users from domain A should be able to access the service in domain B [only a given group of users] 3. Users are in a Windows domain and should be not asked again to enter any credentials to access the service in domain B What we need to achieve is.. User logs in to his Windows machine and seamlessly accesses the service in domain B - with no additional authentication steps. Pattern - as per the diagram above.. 1 & 2 : User talks to Kerberos KDC [TGS] - authenticates and gets a Kerberos TGT. This communication with KDC happens underneath when user logs in to his Windows machine. 3 & 4 : User program using the TGT, gets a Kerberos ticket to access the STS. 5 & 6 : Using the Kerberos ticket issued to the user to access the STS - user program authenticates to STS and obtains a SAML token via WS-Trust. STS also carries out an authorization check to see whether the user is eligible to access the service in domain B. 7 & 8 : User program uses the obtained SAML token to authenticate to the service in domain B. The service will validate that the token is issued from a trusted STS by verifying the signature.

SOA security patterns - Part - I

It's been some time I desperately wanted to get started with the $subject - but things got delayed till I get my blog cleaned up with some missing images.

Sri Lanka lost the 3rd ODI today against Aussies and the match turned out quite boring after few minutes from the start - fixing missing images in the blog was less boring than watching the match..

Here I am ready to blog again :-)

"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations."

That's Wikipedia for you...

SOA has it's own patterns and in security space we have plenty too...

Let me list some of them which I will be discussing with further details in upcoming episodes of this series.

1. Direct authentication with user name and password - SOAP
2. Direct authentication with user name and password - REST
3. Direct authentication with certificates - SOAP
4. Direct authentication with certificates [mutual authentication] - REST
5. In direct authentication with certificates
6. Federated authentication with WS-Trust
7. In direct authentication with Kerberos
8. Authorization Enforcer pattern - fine grained authorization with XACML
9. REST client authenticating to a SOAP web service with user name and password
10.SOAP client authenticating to a RESTFull service with user name and password
11.Securing a service with multiple security policies
12.SSL bridging
13.Trusted Sub System pattern
14.Message Interceptor Gateway pattern
15.Secure Message Router pattern
16.Assertion Builder pattern
17.Credential Tokenizer pattern
18.Secure Service Facade pattern
19.Audit Interceptor pattern
20.Interceptor Validator pattern
21.Secure Pipe pattern

We have implemented all those security patterns with WSO2 products in various client deployments.

In the upcoming sessions of the SOA Security Patterns series I will cover them all with implementation details.