By Prakash Yamuna on Oct 09, 2011
Now that Fusion Apps 11g is generally available - I thought I would share some experiences in terms of how Fusion Apps leverages OWSM for it's Web Services security needs.
Fusion Apps is built on Fusion Middleware and mentioned in the various keynotes - there were a few key design principles that played a significant role. These are:
a) Secure By Default
b) Externalize Security from Applications and Declarative Security via Policies
c) Open and Standards based
d) Ease of Management
I described "secure by default" in one of my earlier blog posts. This is a key design principle that drives the security architecture for Fusion Apps. Given that there are more than 100+ modules in Fusion Apps and more than 2000+ Web Services and Web Service Clients - as more and more modules and web services are deployed - the ability to have security by default is a key consideration.
Why do we need "secure by default"?
In in Fusion Applications we have products like ERP, HCM, etc that provide mission-critical capabilities to many organizations. Protecting data and business transactions is critical to reducing security risk;
How does Fusion Apps address "secure by default"?
Fusion Applications leverage the Global Policy Attachments (GPA) feature in OWSM to address this design goal. In addition, there are certain Web Services (Web Service Clients) in Fusion Apps that integrate with Partner systems - in this case the security requirements are different and hence LPA is used to secure these Web Services and Web Service Clients at Design Time in JDeveloper.
Externalize Security from Applications & Declarative Policy based Security
Fusion Applications provide a lot of functionality - however we seed that:
a) Companies - extend Fusion Applications by building their own applications and integrating their applications with Fusion Applications.
b) The security requirements of Applications change over a period of time - these can be due to regulatory needs, integration needs, etc
Building security into the applications layer makes it brittle when the security requirements change, thus rather than building security into the applications layer - it is built into the Middleware layer and externalized from the Applications layer. This enables new applications that customer's may build to extend Fusion Apps to leverage the same capabilities. In addition, if the security requirements change, declarative policy based security allows one to make changes without having to change any code either in the Middleware layer or in the applications layer.
How does Fusion Apps address this design goal?
Fusion Apps leverages OWSM. OWSM provides a declarative policy based approach to addressing Web Services Security and allows one to externalize the security from Applications.
Open and Standards based
As mentioned earlier Fusion Applications expose a lot of functionality as Web Services. Many of the modules of Fusion Applications integrate with other modules via standards based Web Service interfaces. The rationale for this architecture is multi-fold:
a) Exposing functionality as Web Service interfaces - enables customer's to integrate their custom applications with Fusion Applications via Standards based interfaces.
b) Using Web Service interfaces to connect between modules enables us to build a more modular, less decoupled system and leverage the advantages of a SOA based architecture.
c) Exposing functionality as Web Service interfaces - makes it easier to deploy Fusion Apps in mixed topologies (some modules maybe on-premise and some maybe on-cloud) and still be able to integrate b/w the
d) Exposing functionality as Web Service interfaces - makes it easier to integrate/interoperate with Partner systems or other Oracle Applications - ex: Siebel, Peoplesoft systems - thus allowing customer's the choice for incremental uptake of Fusion Application modules.
These Web Services are also secured via standard Web Services Security policies - thus allowing for:
a) Standards based security.
b) Standards based interoperability with Partner systems.
How does Fusion Apps address this design goal?
Fusion Apps primarily leverage SAML token based policies for identity propagation. However not all Partner systems may support SAML - thus - Fusion Apps also support - Username Token.
Ease of Management and Being Able to Modify Default Security Posture
Fusion Apps has nearly 2000+ web services and web service clients. Fusion Apps ships with a default security posture. This default security posture may not be suitable for all companies. Given the number of Web Services and Web Service clients, being able to change the security policies if the security requirements of a company or organization change - is critical. However changing the security requirements needs to be easy and cost effective.
How does Fusion Applications address this design goal?
Fusion Apps again leverage Global Policy Attachments to address this design goal.
In a future blog post - I will discuss more concrete use-cases and lessons learnt from the Fusion Apps - which I hope customer's will find useful.