Wednesday, May 27, 2009
OES - Web Services SM configured with OAM SSPI Connector
OAM - Access Management - ASDK - with custom web services wrapper
Both definitely good choices. A few quick thoughts on when each would be appropriate.
OES WS SM can be configured with OAM SSPI connector to consume OAM sessions - ObSSO cookies, but it can also be configured to consume SAML Assertions. It can be configured to return, in response to an assertIdentity call different types of tokens, including a SAML assertion. On the authorization front, OES does fine-grained authorization. The Web Services wrapping the Java API is what it is - works well, but is not integrated with any container. It also exposes a standard authorization service with XACML.
OAM with custom web services wrapper works with ObSSO cookies and focuses on coarse grained authorization, like what is typically required for URLs. The Web Services implementation, since its built on-top of the container is integrated. Also, its very simple to take a POJO and turn it into a fully functioning web-service.
So, basically if you need to extend OAM to have a SOAP interface for authentication and coarse-grained authorization, wrapping the ASDK in a web-service seems like the way to go. If you need more of a heterogeneous implementation which is expected to integrate using standards like SAML and XACML and has fine-grained authorization requirements, then the OES WS SM solution makes the most sense.
Wednesday, May 20, 2009
The Policy Enforcement Point (PEP) intercepts the request and asks the Policy Decision Point (PDP) to evaluate the request. The PDP responds - yes/no - and then the PEP either lets the call continue or blocks the request. A good example of this whole model can be found in the XACML spec.
So, when looking at the question "Can OES be used to secure POJOs?" we need to looks at both parts of the model - PEP and PDP.
On the PDP side, OES is sufficiently flexible to perform the task. The OES resource model allows for a hierarchal names. This maps nicely to Java class names:
Using this model, you could write policies to block access to packages or classes - sorta useful. But probably not the main case. What about methods? There are really two choices here. The first is mapping the method invocation to the action.
The second is going with a generic action and putting the action as the lead note of the resource:
The latter makes it easier to write policies for "all actions on an object".
Now, what about access control at the instance level? I want to write a policy that says that 'Joe can get the balance of the customer if the customer is in state="MA"'
grant (//priv//invoke, //resource/com/foo/Customer/getBalance, //user/foo/Joe) if state="MA"
Makes sense, but how does OES get the state of the customer object?
OES has the ability to pass information from the PEP to the PDP. This includes Java objects. Either the PEP could use Java reflection to pass the attributes or the PEP could pass the instance (assuming its serializable) and OES could use attribute retrievers to get the values from the instance.
In a previous post, I discussed customers' desire for PEPs (Policy Enforcement Points). So, how would you go wire this in?
It depends on what container, if any, you are using. With no container, you need to look at AOP to insert these calls pre-method. In spring, you could do this with ACEGI + OES. If you are willing to make some small code changes, maybe look at securing the classes with custom java Permissions.
In my experience, I haven't seen a need for securing all POJOs. If this is the case, then use Java Security and custom permissions. What I have seen is the need to secure a small number of very sensitive classes. In this case, look at what the container provides, or possibly modifying the class to explicitly call to OES.
Monday, May 18, 2009
The new version of the Oracle Enterprise Single Sign-on Suite version 10.1.4.1.0 is officially released and is posted to OTN for download. Check it out.
Product Download on OTN : http://download.oracle.com/otn/nt/ias/101401/as_windows_x86_esso-suite-multi-language-101410.zip
Docs for 10.1.4.1.0 : http://download.oracle.com/docs/cd/E12472_01/index.htm
Here are some of the new features in this release that is worth exploring
- New ESSO-LM User Interface
- Updated Change Password User Interface
- Administrative Improvements
- Notification Service
- Do not Add Predefined Templates to Bulk-Add by Default
- Avoid Sending Admin Overrides for Certain Registry Keys
- Domain Password Validation for Credential Sharing Groups
- Infrastructure to Support Reporting Server
- Authentication Enhancements
- New Windows Logon v2 Installer Options
- Network Provider Support for Windows XP and 2000
- Share Authenticator Credentials with Synchronizer
- LDAP v1 Logon Method now supports multiple Active Directory domains.
- Newly Supported Systems
- PuTTY v0.60
- Newhart Systems BLUES 2000
- Jolly Giant QWS3270 PLUS v4.4
- Mozilla Firefox 3.0
- Siemens DirX Directory v8
- IBM Lotus Notes 8.0.1
Tuesday, May 5, 2009