Wednesday, January 18, 2012

Fusion Security – Apps Edition

When we first started this blog more than 2 years ago, we debated about whether to name it “Fusion Security” or more specifically “Fusion Middleware Security”. We all work in the Fusion Middleware team on Fusion Middleware but even back then we saw Fusion Applications coming down the pipe and after all Fusion Apps is a set of big business applications whose principal distinction (in my opinion) is that it is the first set of business applications to be built on a truly modern middleware platform.

The much anticipated Fusion Applications was recently released. For those of you unfamiliar with Fusion Apps, it is composed of several families of applications (CRM, Financials, HR, Supply Chain, Procurement etc) that comprise the next generation version of Oracles Apps portfolio (PeopleSoft, E-Business Suite, Siebel etc.) and as I said it is built on top of most of the Fusion Middleware products that currently exist today.

Welcome Apps Community

I will start off by welcoming those in the Oracle Apps community to the Fusion Middleware community and specifically the FMW security community. The middleware products may seem complicated, even overwhelming at first, but they are good powerful products that you can build your business upon.

Why You Should Care

What does this mean for those of us in the Fusion Middleware Security community? Why should we care?

For one Fusion Apps has been driving much of the direction of Fusion Middelware for some time and now is your opportunity to see what it is all about and how the Middleware you know and love is used. In this post I’ll provide an overview of this usage and follow up with much more detail in the coming months.

Secondly, I think our community is about to get much larger. Every Fusion Apps customer will become a Fusion Middleware Security Customer. So, I’ll also take the opportunity now to say welcome to all the new Fusion Apps architects, developers, and administrators out there that may happen across this post.

Thirdly, Fusion Applications is a very large and complex set of applications. Oracle has created an Enterprise Deployment Guide specifically discussing how the Identity Management products that Fusion Apps utilizes should be deployed. It is worth reading this just to get an idea for what Oracle considers as reference architecture for an IAM environment that supports large business applications.  You can find the Enterprise Deployment Guide for Oracle Identity Management (Fusion Apps Edition) here.

I myself have been very involved in the initial rollout of Fusion Applications and will continue to be very much involved along with other members of this blog in helping to advise customers on the security technology involved in Fusion Apps deployments.

What This Doesn’t Mean

With all that being said, while I do think the release of Fusion Applications is exciting and important to those of us in the Fusion Middelware Security community, I have heard some messaging around Fusion Applications and its impact on Fusion Middleware that I think oversells the importance of Fusion Apps and is ultimately incorrect.

I’ve heard it said many times that customers should closely align their use of our Fusion Middleware products to how they are used in Fusion Applications. While I agree that customers should be mindful of how FMW is used in Fusion Apps, I simply don’t agree with that statement.

Fusion Applications is a set of specific applications, namely business applications, which use our Fusion Middleware Security stack in a specific set of ways. They do not make use of every feature or even every product in our FMW Security stack. Our Fusion Middleware customers use our middleware products in a wide variety of ways, to create and support a wide variety of applications, with a wide array of business requirements, in a large variety of environments. Some of the differences between what our customers are trying to achieve with Fusion Middleware vs. what we achieved with Fusion Middlware in Fusion Apps means that customers can and should take different approaches from what was taken with Fusion Applications.

What FMW Security Is In Fusion Apps

Now that my rant is out of the way, I’ll proceed to talk about how Fusion Middleware Security is used in Fusion Applications on a product by product basis. Again, for a more detailed discussion at this time see the Enterprise Deployment Guide for IDM (FA Edition).
  • Oracle Internet Directory (OID) serves as the store for OPSS security policies and as the default store for Fusion Apps users.
  • Oracle Virtual Directory (OVD) serves as a go-between layer for user stores when OID is not being used (and optionally when OID is being used. It is also always used in conjunction with OIM for a feature called LDAP sync which provides real time synchronization of users between OIM and an LDAP directory.
  • Oracle Access Manager (OAM) provides authentication and singles sign-on (SSO) for Fusion Apps. It is worth noting that OAM runs in a special mode in Fusion Apps build outs and does not by default provide authorization, even course grained, for Fusion Apps. This means that some careful consideration will have to be done by customers wanting to use a single OAM deployment for Fusion Apps and other applications in their environment.
  • Oracle Identity Manager (OIM) helps provision users to the FA environment and provides delegated management and self service user management services to the Fusion Apps environment.
  • Oracle Platform Security Services (OPSS) provides the fine grained authorization for the application in Fusion Apps as well as an assortment of other functions such as LDAP connectivity and key management.
  • Oracle Web Services Security Manager (OWSM) provides web services security (WS-SEC) for both FA internal web services communication and the external web services interfaces to FA.
  • WebLogic Server serves as the core container for Fusion Apps and so WLS security is part of the picture. Specifically, identity asserters and authenticators (SSPI providers) are configured in FA. Other WLS security areas such as transport (SSL) security and node manager security also come into play.
  • Oracle HTTP Server (OHS) serves as the web tier for Fusion Apps. There are actually two web tiers in a Fusion Apps deployment. The first web tier is the front end to the IDM environment and the 2nd is the front end to the Fusion Apps themselves. Both web tiers will have OAM webgates on them. Beyond that SSL is the main security consideration you will have to configure / manage.
  • SOA Suite – SOA Suite is widely used throughout Fusion Apps including (as most of you know) its use as the workflow engine for OIM. There is a good deal of security in SOA Suite to manage including transport and message level security.

5 comments:

  1. Dear Brian,

    Being a partner to Oracle, I follow your blogs and I really learned lot of FMW technical stuff that no where else available. Really enjoyed reading your and the teams posts.

    Please keep posting. It is really useful to get a different view points from SMEs inside Oracle. a big THANK YOU.

    Cheers.

    ReplyDelete
  2. Vijay,

    We appreciate the kind words and support!

    Thanks,

    Brian

    ReplyDelete
  3. Hi Brian,
    As I usual I don't miss even single post and this post is again which I find very useful for those who are new to Fusion Apps.


    Just one query from your post above , you mentioned

    "It is also always used in conjunction with OIM for a feature called LDAP sync which provides real time synchronization of users between OIM and an LDAP directory."

    Is OVD mandatory for OIM LDAP Sync ? If I am not wrong, from 11.1.1.5 onwards you can use OIM LDAP sync without OVD (via libOVD). Is OVD mandatory for FA 11.1.1.5.1 with OID & OIM for LDAP Sync ?


    Atul Kumar
    http://onlineAppsDBA.com

    ReplyDelete
  4. Atul,

    You are correct about OIM and LDAP sync using libOVD.

    With Fusion Apps though, it is being recommended that people use the full libOVD. The reason for this is that the "split directory profile" solution described in Chapter 10 of the latest IDM EDG for FA requires the full OVD. Beyond that, the full OVD just gives increased flexibility that FA customers may need up front or down the road and it is seen as better just to get everyone using the full OVD upfront.

    Could you make libOVD work in an FA environment that didn't need a split ID store solution? Probably. However, the tooling being provided to create the IDM environment for FA assumes the use of OVD.

    I hope that helps.

    ReplyDelete
  5. Very good post specially for who are starting in Fusion Application

    ReplyDelete

Note: Only a member of this blog may post a comment.