When we started on our SOA ERP/CRM System Project, I was amazed by the sheer volume of hand wringing from our SOA vendor about "security".
Their flagship SOA security project was an OEM from "AmberPoint", when SUN purchased AmberPoint, well, that went out the window. So, not being dead from the neck up, I went looking for options (though my vendor assured me that, within two years, they would have a replacement product that would be amazing! Eighteen months later, I am still waiting, to be amazed that is).
In the world of SOA security, there are many players, but a few really stand out. We have a substantial investment in Oracle products, some that have been implemented well, some that have not been implemented well. To be fair, Oracle stuff, by and large works as advertised, and then some, if you can stomach the price point. From my vantage point, it was not about cost, but about risk. What would be the risk of having our authoritative source for the user object having an Oracle System of Record (SOR) and the authoritative source for authentication being an Oracle product?
Too much for my blood. Something about eggs and baskets my Mother taught me about.
We then bumped into a vendor, "Layer 7 Technologies". From a due diligence perspective, we had a side-by-side bake off: Oracle Corporate, with some excellent Systems Engineering talent; and Layer 7 Tech with their top Ninja, "Ben". Some high stakes technical guy, dog on the street butt sniffin' later, we had validated that the Layer 7 SOA Gateway would meet or exceed all our CY 2011 ~ 2013 requirements.
So, being good Corporate Citizens, we scheduled a "bake off". (...NOTE TO SELF: Never bring a feather duster to a knife fight...)
During the integration proof of concept (POC) the Oracle integrator (name withheld to protect the innocent) with five weeks of prep time, could not stand up the Oracle Identity Mgmt Suite during the five day on site POC. Finally, on day five, at 6PM, the system engineer from Layer 7 walked the Oracle integrator team members thru setting up their products and they were able to connect (this did though, highlight the level of expertise that Layer 7 brought to the dance). Needless to say, I went looking for another integrator on Monday morning.
That leads me to the most stellar Identity Management Integrator team I have ever worked with, IDMWORKS, (but that is another story...).
So, our ERP/CRM application we are building is replacing a pool of ERP/CRM systems in use by companies we've purchased over the last fifteen years (one ring to rule them all!). When we purchase someone, it's about profit (as it should be) so we are slow to re-brand them (or mess with them), as long as they stay profitable. If that slips, we assimilate them in a BORG'ish fashion. So, the short version: our shiny new web user interface requires the consumer/user to enter their USERID in the form of an LDAP "UserPrincipalName" (UPN), which allows the system to differentiate an external actor in an easy manner. Our logon sequence has a few steps:
(1.) we validate the credentials from our Apache front end;
(2.) we pass these thru our Layer 7 SOA Gateway (recursive data validation and payload inspection) via SSL;
(3.) then Layer 7 hands the credentials off to Oracle Virtual Directory(OVD) over SSL;
(4.) then OVD passes the credentials to Oracle Internet Directory (OID) (this step will make integration with Oracle Financials later, easier) over SSL;
(5.) then OID uses the credentials to bind to Microsoft Active Directory, over SSL. If the bind is successful, OVD queries it's subordinate ATTRIBUTE stores for ATTRIBUTES associated with the UPN and passes this back to the web U/I which caches the ATTRIBUTE(s) and/or ENTITLEMENTS.
The web U/I can use the cached ROLE and ENTITLEMENT data, based on the relative risk rating of the business process and associated SERVICE(s) and/or OPERATION(s). The web U/I does some rudimentary ROLE to UPN, ATTRIBUTE matching before passing a request to a back end SERVICE or OPERATION, however, our Layer 7 SOA gateway protects each service and/or operation individually by validating the ROLE, UPN and/or ENTITLEMENT ATTRIBUTE data presented (as well as the source of the request), before allowing the customer/user to call the back end SERVICE or OPERATION.
This pattern is in response to several OWASP "top ten risks".
For inter-process or service to service communications we require a UML Sequence Diagram from the development team to document the communication pattern and AUTHENTICATION token requirements, before we can set up and enforce technical controls between these forms of system level communications. Our Layer 7 SOA Gateway device(s) can craft a custom token (STS) based on the WSDL of the SERVICE or OPERATION being consumed.
### More on this topic later ###
REFERENCE MATERIAL:
Michael Becher's excellent and timely reference on Web Application Firewalls: http://amzn.to/2fSwcHD
Erl Thomas on SOA GOvernance, another timeless reference: http://amzn.to/2xTCQSp
No comments:
Post a Comment