This is a topic that spans both SOA and Access Management (OES).
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 ;)
More soon.
Wednesday, August 12, 2009
Tuesday, July 14, 2009
Authorization Decisions - To Pre-Cache or Not to Pre-Cache, That is the Question
There is a common pattern of entitlements solutions which "require" authorization decisions to be pre-cached. What I mean by pre-cached is that at startup, all of the authorization decisions for all of the users for all of the resources are loaded into an in memory cache. This in-memory cache can be either local to the application or in a central location(s). There are a few reasons why to do this. The most obvious is performance - finding a entry in a HashMap should be very very fast (sub microsecond). The other reason I've heard is a high availability requirement. The in-memory cache is also backed-up onto disk (securely) so that in the case that the user can authenticate to the system but the systems that the PDP needed information from (PIPs) are not available, a decision can be returned.
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.
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.
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
Oracle Identity Federation 11g is Now Live
We launched Fusion Middleware 11g today. It's not just announcements - the software is ready to download.
There is more information on the updated Identity Management site.
It's a major milestone for Oracle Identity Federation reflecting over 2 years of work.
So what is new?
First - all 11g Identity Management components are now integrated with Enterprise Manager Fusion Middleware Control (EMFMC). EMFMC provides customers with operational monitoring (is the server up/down, how is it performing) and is the single point of access for logging and auditing.
Second - Oracle Identity Federation now is a J2EE app and comes deployed on Oracle WebLogic Server 10.3.1 OOTB.
Third - we introduced a new unified architecture across all protocols - Oracle Universal Federation Framework. It is much easier now to plug the OIF into existing environments and to build integration extentions.
To learn more about the benefis of the new version, visit the product documentation site.
Over the next few posts - I will continue to provide more information of OIF 11g.
New OAM 10.1.4.2 Certifications Released (June 2009)
The following new OAM 10.1.4.2 Certifications have been released:
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
Additional Resources:
OTN (download) location
OAM 10.1.4.x Support matrix location
OAM 10.1.4.x Package list location
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
Additional Resources:
OTN (download) location
OAM 10.1.4.x Support matrix location
OAM 10.1.4.x Package list location
Wednesday, May 27, 2009
Authentication and Authorization - Identity Services in OAM and/or OES
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.
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 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
Thursday, February 19, 2009
Standard Life Chooses Oracle IdM
CBR Online posted an interesting article about Standard Life's decision to use Oracle access management products to secure it's sensitive applications. Standard Life will be using OAAM and the other access products to protect both customer and employee facing applications. Read the article...
http://www.cbronline.com/news/standard_life_to_roll_out_oracle_id_190209
http://www.cbronline.com/news/standard_life_to_roll_out_oracle_id_190209
Subscribe to:
Posts (Atom)