Wednesday, August 12, 2009
Again, the steps in the post are not officially supported.
Now that I've got the WLS SM running inside of the domain, I'm working on configuring a Java callout inside of a BPEL process to OES. Better get my DOM API guide handy ;)
Tuesday, July 14, 2009
To be fair, I'm not sure that this pattern is common across all customers, but I have seen it many times in Financial Services. This makes a lot of sense...very fast, very available authorization solution - fits well with things like front-office trading systems. So, what's the problem?
So there seems to be a couple of issues with this model.
- Issue 1 - Update latency. If there is a change, how long does it take to get that change to be enforced in an application? Well, it depends on the scope of the change...for example, if a country changes the rules on what constitutes an adult or what constitutes legally married, then you may have to re-calculate the entire cache, and this can take a long time...hours, days? If its a more isolated change, like a privilege on an account, then the change is more isolated, but this touches on the second issue
- Issue 2 - Cache consistency. Since this model is really for very fast, very available solutions, you're not going to have one instance of the cache. So, now you need to make sure that you've updated all the copies of these records, and probably need to make sure that its done transactionally...don't want different behavior based on which server in the cluster you hit. These first two issues can be solved with a really advanced distributed cache, but, the third issue and the one that seems to be the "killer" for pre-caching
- Issue 3 - Context based authorization. Simply, "What if the authorization decision depends on some information I don't know until request time?"
The simple answer would be in the application session, but what I've done on a number of occasions, and has worked very nicely is stored it in side of the Subject as Principal objects. This approach covers most of the same HA use cases as pre-caching with disk back-up, except in this solution if those systems are down when you try to authenticate you won't be able to login - depending on how you set the JAAS control flags. Also, this lends itself very nicely, in the case of OES, to the creation of a custom authentication provider - basically a JAAS Login Module. Its purpose is to go fetch the static information and hold onto for the duration of the JAAS Subject. This is effectively the same as the session. This approach also adds "no time", since most authorization requirements don't include authentication. The business requirement is that transactions are processed quickly - sub ms - and they will be since all of the information is stored inside of the JAAS Subject, in memory. Also, the latency of change goes way down...the user gets new entitlements every time they log out.
Now that I've re-factored the static data into the JAAS Subject adding context based authorization is pretty straight forward. The new "policy combining algorithm" is in most cases allow if the static entitlements are granted and if there are context based authorization policies, those policies must evaluate to "grant". In OES, this can be done by:
DENY (//priv/all, //sgrp/foo/allusers, //app/foo) if not static_entitlements_granted()
In this model all of the logic is burried inside of the custom evaluation function, but I could have used attribute retrievers to parse the Principal objects in the Subject and exposed more of the logic into the policy.
DENY (//priv/all, //sgrp/foo/allusers, //app/foo) if not "ent1" in [user_entitlements]
So now that the existing rules are in place, just go add some new context based authorization
GRANT (//priv/read, //sgrp/foo/allusers, //app/foo/sensitive_materials) if authentication_method = "strong"
Context could include network, authentication method, user limits, historical patterns (OAAM), time of day etc.
In order for this type of model to be a true replacement for pre-caching, it assumes that the underlying authorization engine is fast...that it can do authorizations in the sub-ms range. I can't disclose any confidential information in this forum, so you'll have to draw your own conclusions about the performance of OES. I can say I've built solutions like this with a number of customers, and they've been very pleased with the result.
Wednesday, July 1, 2009
1) Oracle HTTP Server (OHS) 10.1.3.4+ v2.0 (64-bit) WebGate for HP-UX Itanium 11.23 and 11.31
2) Lotus Domino Web Server 8.5.x (64-bit) WebGate for Windows 2003 EE SP2+ and Windows 2008 EE - x86-64 hardware
3) Sun Java Webserver 7.0.x (64-bit) WebGate for Solaris 10 (64-bit) - SPARC S2 hardware
OTN (download) location
OAM 10.1.4.x Support matrix location
OAM 10.1.4.x Package list location
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
Thursday, February 19, 2009