Oracle API Gateway (OAG) : Concept & marriage with SOA & Mobile

Oracle API Gateway is a standards-based, policy-driven, standalone software security solution that provides first line of defense in Service-Oriented Architecture (SOA) environments.

It enables organizations to securely and rapidly adopt Cloud, Mobile and SOA Services by bridging the gaps and managing the interactions between all relevant systems.

Oracle Web Services Manager(OWSM) is generally used for application security of a particular service,most customers have any use cases around DMZ or Perimeter Security for Web Services. This product serves as a part of the enterprise security solution.

This would be typically for customers needing access to web services from the internet, similar to how we access a web application. OAG can do a  lot of validations
and route the requests only once those checks have passed. This may also be a typical use case for Mobile Applications which use REST Web Services at the backend.

I have seen a strong value in this security product for all SOA and Mobile projects.

Here’s a high-level request flow :

There are many advantages that OAG can provide :

–   Authentication, Authorization (Leverages existing LDAP like AD ; existing IDM platforms for this – RSA AM, CA Site Minder, Oracle Access Mgr)

–   XML Acceleration, Throttling, Caching, Protocol translation (REST to SOAP and vice versa), Dynamic routing, SLA enforcement

–   Identity Propagation and Credential Mapping , Filter threatening content (XML Bombs, DOS Attacks, Virus)

Oracle OEMs (or Original Equipment Manufacturing) the OAG product from AxWay – AxWay’s gateway product is rebranded for Oracle as OAG, and is almost identical.

Quick Demo : https://www.youtube.com/watch?v=MWunxvZnB1A

Oracle  Datasheet

OAM Single-Sign-On (SSO) Deployment Architecture : Best Practice

Recently I came across couple of OAM Deployment Architectures which have been implemented and can potentially cause multiple issues - 

• Using the same OHS Instance which has a webgate deployed on it for reverse proxy to OAM Servers in addition to the target application which needs to be protected (e.g. WebCenter)
• Front-ending OAM Servers directly with an external Load Balancer(LBR) skipping the Web Server layer altogether

Ideally, OAM should be front-ended by a web server/OHS instance of it's own to 

• Allow separate streams of HTTP traffic(in addition to one for Application) 
• Scale the SSO architecture to other target applications - 
• In case the same OAM Server is used for a new application which needs to be SSO enabled as well, the standalone OHS which just services requests to OAM (and doesn't have any webgate on it) is a must!
• This would also ensure that any files needed to be cached (like javascript, css etc) for any OAM related applications can be cached at the OHS layer

(Image Courtesy : A-Team Blog) 

If we have to use a Load Balancer(LBR) to directly front-end the OAM Server instead of an intermittent OHS(probably due to cost constraints), we should have this LBR within the corporate network (in addition to an external LBR which front-ends the other OHS instance(s) for applications) and not in the DMZ to prevent the security risk of an external LBR based in the DMZ exposing the OAM located in the Application Tier directly.

Courtesy  :
1) Forum Post which was logged as few items in the A-Team blog mentioned below were not crystal clear
2) A-Team Blog