Message Interceptor Gateway pattern is the one that directly comes in to my mind.. We have implemented this at many customers with WSO2 product stack.. ESB, IS, GReg and WSAS/DSS.
This pattern provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages. The security tasks include creating, modifying, and administering security policies for sending and receiving SOAP messages. It helps to apply transport-level and message-level security mechanisms required for securely communicating with a Web services endpoint.
Isn't this the functionality we are looking from a Security Gateway..?
BTW, if you are building a Security Gateway, you can't ignore OWASP XML Security Gateway Evaluation Criteria project.
The OWASP XML Security Gateway Evaluation Criteria Project (XSGEC) defines an open standard for evaluating XML Security Gateways, such as those used to protect and provide security services for Web services applications.
This project categorizes the evaluation criteria in to 9 sections.
1. Authentication
2. Authorization
3. Audit Logging
4. Deployment Architecture
5. Content Validation
6. Management & Metrics
7. Transformation
8. Tools
9. Performance
The authentication section describes the support at the service level and message level for inbound and outbound communication to the Security Gateway.
In bound traffic can be protected with any of the following security techniques.
- Mutual SSL
- HTTP Basic Authentication
- HTTP Digest Authentication
- WS-Security Username Token Authentication
- WS-Security X.509 Certificate Based Authentication
- WS-Security: Kerberos Token
- SAML Authentication assertion
- Validation against Active Directory
- Dereference Active Directory Federation Service
Outbound traffic can be protected with following techniques..
- Mutual SSL
- HTTP Basic Authentication
- HTTP Digest Authentication
- WS-Security Username Token
- WS-Security X.509 Certificate
- WS-Security: Kerberos Token
- SAML Authentication assertion
- WS-Federation assertion
Looking at the Authorization section - it covers,
- XACML
- SAML
- LDAP
Being part of the WSO2 Security team for years now, it's so natural to think, how we meet these criteria with WSO2 Product Stack..?
In fact we do already... Only thing we lack is the full support for WS-Federation. Even a set of students from University of Moratuwa - currently working on adding WS-Federation support for Rampart - which is the security module of Axis2.
To be more precise - we have already done this at some of our customers.
Let me briefly share some of my experience with a customer who is highly concerned about security.
They had the backend services already implemented with WCF and protected with Integrated Windows Authentication[IWA] - hosted in IIS.
They have three types of clients who need access to the BE services.
1. Windows Client
2. C++ client running on a Linux box
3. Third party client - out side their domain
Windows client doesn't have any issues in accessing the BE services - with IWA.
C++ client had some technical challenges. It is already developed and only way it supports securing the communication channel to the BE services is through BasicAuthentication.
Third party client can be developed on any platform. The challenge is - we do not know how to authenticate users who are coming from a different domain - and they also need to integrate with internal windows authentication.
Apart from this - we also need to authorize each and every user.
Sounds interesting ? ;)
Let me summarize the requirements..
1. Windows Client -- [Authentication with Kerberos] -- [Authorization] -- > BE Services
2. C++ client -- [Authentication with BasicAuthentication] -- [Authorization] -- [Authentication with Kerberos] --> BE Services
3. Third Party client -- [Authentication?] -- [Authorization?] -- [Authentication with Kerberos] -- > BE Services
We need define a method to authenticate third party users - who we do not have access to the credential store -- that is WS-Trust
We need to do a credential conversion from BasicAuthentication to Kerberos and WS-Trust to Kerberos.
Apart from this we need to have an authorization scheme as well.
Let me explain our solution.
We decided to have WSO2 ESB - acting as a security gateway - implementing the message interceptor gateway pattern.
Also - we decided not to propagate end user credentials to the BE services. It's up to the ESB to authenticate and authorize users and occupy the trusted sub system pattern to authenticate to the BE with Kerberos.
1. Windows Client -- [Authentication with Kerberos] --> ESB -- [Authorization with XACML] -- [Authenticating with Kerberos] -- > BE Services
2. C++ client -- [Authentication with BasicAuthentication] --> ESB -- [Authorization with XACML] -- [Authentication with Kerberos] --> BE Services
3. Third Party client -- [Authentication with WS-Trust] --> ESB [Authorization with XACML] -- [Authentication with Kerberos] -- > BE Services
The above gives us a unified authentication and authorization scheme across three different clients.
It's true that with this pattern we do not pass user credentials to the BE services. But, still we need to send the user name corresponding to the request to the BE. In that case we wrote a mediator to extract the user name from the incoming request and attach it to the out going message form the ESB to the BE services.
Okay.. one last question.. It's clear that we can define an authorization scheme for internal users - based on their roles.. But.. how do we authorize third party users..?
All the requests [based on WS-trust] are signed by the corresponding STS. So - with the signature - we can identify to who a particular user belongs to. Internally we define roles for each and every partner and once via the signature we identified the partner, we can easily figure out the mapped role that particular user belongs to. The XACML policy authorizes the user against this role.
I guess that's pretty much the solution to that specific problem - although in my description I do not cover how to govern both the security policies and XACML policies - which should also be part of a Security Gateway Solution.
If you are further interested in reading about more features that you should look into, while building a Security Gateway - it's highly recommended that you go through Security Gateway Buyer's Guide.