Recently, the question came up on how to expose authentication and authorization as identity services inside of the Access Management Suite.
Two solutions:
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 27, 2009
Wednesday, May 20, 2009
Using OES to Secure POJOs - Fact or Fiction?
In providing access control, there are two "main" functions - policy enforcement and policy evaluation.
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:
//resource/com/foo/Customer
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.
//priv/getBalance //resource/com/foo/Customer
The second is going with a generic action and putting the action as the lead note of the resource:
//priv/invoke //resource/com/foo/Customer/getBalance
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.
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:
//resource/com/foo/Customer
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.
//priv/getBalance //resource/com/foo/Customer
The second is going with a generic action and putting the action as the lead note of the resource:
//priv/invoke //resource/com/foo/Customer/getBalance
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
Oracle Enterprise Single Sign-on Suite version 10.1.4.1.0
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
BT and Oracle: Managed Fraud Reduction Service
British Telecom and Oracle are working together to help customers prevent fraud and verify identity with a combined solution. The combination of the real-time behavioral profiling, transaction analysis and identity verification make MFR a powerful and complete solution for customers in many different verticals. Here are some good articles written recently about this unique new offering from two industry leaders.
http://www.anti-keylogger.org/news_world.cgi?id=5356
http://www.pcw.co.uk/vnunet/news/2241280/bt-unveils-managed-security
http://uk.news.yahoo.com/16/20090428/ttc-infosec-2009-bt-unveils-managed-secu-6315470.html
http://www.anti-keylogger.org/news_world.cgi?id=5356
http://www.pcw.co.uk/vnunet/news/2241280/bt-unveils-managed-security
http://uk.news.yahoo.com/16/20090428/ttc-infosec-2009-bt-unveils-managed-secu-6315470.html
Subscribe to:
Posts (Atom)