Oracle Entitlements Server supports three types of Attributes:
- Context Attributes: These are passed by the application as part of authorization request
- Dynamic Attributes: These are automatically fetched by PDP as needed (i.e. external PIP)
- Resource Attributes: Hierarchical attributes defined on a resource
The demarcation between Context attributes and Dynamic attributes is fuzzy. During policy execution, if PDP needs a value it first checks the context to see if an attribute is present. PDP will contact an external PIP only when the attribute is missing in the authorization request context. Oracle Entitlements Server uses this approach because it gives a lot of flexibility. If an application knows the value of an attribute, it can add it to the authorization request context. Doing so saves a network round trip for PDP. However an application is not burdened with keeping track of all the attributes required by PDP, because PDP will automatically fetch these values on demand using PIPs.
When adding conditions, there a know issue which might case exceptions. If you run into this problem, contact Oracle support for a patch.
To keep things simple, let us use Java SM (Hello OES World) to get started. Run the Hello OES World Java SM application and make sure that you see a Permit. This way we can be sure that we are starting out with a clean env.
Procedure to add an attribute based condition to authorization policy
1) Log into Oracle Entitlements Server Admin UI (e.g. http://localhost:7001/apm)
2) Navigate the Browse Tree on the left and double click on Attributes
3) You should see the screen below. Click on New
4) You will see the attribute creation screen. Fill-in values show below (for name use lower case “l”):
5) On “Location” tab click x to close it
6) On “Search Attributes” tab click x to close it
7) On the “home” tab, click on “Search” under “Authorization Policies”
8 ) In the “Search Policies” screen, click on Search, you should see this authorization policy
9) Select your policy and click on “Open”
10) You will see the regular policy screen
11) Scroll down and click on “Edit Condition”. You should see this pop-up
12) Select attribute “location” can click on “Add”
13) You should see the screen below, for Value type “London” and click on “Add”
14) You should see expression below, then click on “Done”
15) You will go back to the main policy screen, Click on “Apply” to save the policy
16) Click on “x” in your authorization policy tab to close it
17) Click on “x” in your “Search Authorization Policy” tab and close it
18 ) Double click on your application in the browse tree on the left, you should see the application screen
19) Click on Policy Distribution Tab
20) Select any SM and click on “Distribute”
This completes creation of attribute based policy and distributing it.
Modifying the application to pass the context attribute
1) CD to your SM instance directory (this is the directory where you had the old Java SM app)
2) Run the Hello OES World app (Java SM) without any modification and you should see a deny because we have additional constraints in place
3) Modify the original Hello OES World as show below (you can get full source code here).
4) To set your classpath, run “export CLASSPATH=OES-SM-Home/modules/oracle.oes.sm_11.1.1/oes-client.jar:.”
5) Make sure that Path includes java compiler
6) Compile the java app, run “javac HelloOESworld.java”
7) Start the java application, run “java -Doracle.security.jps.config=./config/jps-config.xml HelloOESworld”. You will see the correct evaluation
8 ) Keep the application running.
9) Go back to the authorization policy and inside the policy condition change the location from “London” to “Paris”.
10) Remember to click on “Apply” to save the policy and then distribute the changes
11) You will see that the application will start to deny authorizations.
You can play around with the condition editor and build complex expressions based on built-in functions and attributes.
Part 2/3 will cover use of dynamic attributes from LDAP
[…] Comments « Oracle Entitlements Server: Attributes (Part 1/3 – Context Attributes) […]
how is scoping typically modeled within a policy. So a user is entitled to a given entitlement but only for a given set of controlled orgs. In other words in a sample app a user has an ‘Edit User’ entitlement but he can only edit users in a dozen orgs that he controls. I believe the controlled orgs would need to be returned as an obligation? But not sure if OES has a mechanism to support scoping….I guess the best way to do this is an external table that manages identities to entitlements for a specific org?
external table coupled with OVD to tie LDAP and the table together
OES provides many facilities for modeling organizational structures. Given that Organizations are often hierarchical, it will be good to use OES concept of Role hierarchy. And then you can use authorization policies to assign privileges to specific roles.
For Example: consider a company which has Sales VP and HR VP:
1) Sales VP has access to future revenue forecasts
2) HR VP has access to salaries of all employees in a company
3) Sales VP only should have access to view salaries of their direct and indirect reports
You can model company’s organization hierarchy as OES Role hierarchy. and create dynamic role assignments policies based on the request. So:
1) “Sales VP” will have “VP” role only when authorization request involves resources in their organization (i.e. Sales Org)
2) “HR VP” will have “VP” role only when authorization request involves resources in their organization (i.e. HR Org)
If a “HR VP” tries accessing “Sales Forecast”, the request will be denied because “HR VP” does not have “VP” role in Sales organization
If a “Sales VP” tries to access salary information of an employee, then “VP” role will be applicable only when the employee is inside their organization. So e.g. “Sales VP” can access salary of of “Sales Director”, but “Sales VP” cannot access salary of “Development Director”
Let me know if you have additional use cases.
Bye,
Subbu Devulapalli
Subbu, when I run the application with the l=’London’ condition, the SM (I’m using RMI) throws an exception that it can’t parse the type of ‘l’. Full stack is below. Is this a known bug? Is there a patch to apply? Thanks!
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTranspor
t.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport
.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:909)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.wles.InternalException: ArmeRUNTIME Exception: unable to parse ty
pe of the decl l, type kind = -1
at com.wles.arme.Credentials_ca.exceptionTransport(Credentials_ca.java:6
06)
at com.wles.arme.Credentials_ca._accessAllowed(Credentials_ca.java:343)
at com.wles.arme.CredentialsImpl._accessAllowed(CredentialsImpl.java:398
)
at com.wles.arme.CachingCredentialsImpl._accessAllowed(CachingCredential
sImpl.java:264)
at com.wles.arme.CredentialsImpl.accessAllowed(CredentialsImpl.java:435)
at com.wles.arme.CachingCredentialsImpl.accessAllowed(CachingCredentials
Impl.java:52)
at com.bea.security.providers.authorization.asi.AuthorizationProviderImp
l.ARMEisAccessAllowed(AuthorizationProviderImpl.java:869)
at com.bea.security.providers.authorization.asi.AuthorizationProviderImp
l.isAccessAllowed(AuthorizationProviderImpl.java:331)
… 14 more
causal exception is:
com.wles.InternalException: ArmeRUNTIME Exception: unable to parse type of the d
ecl l, type kind = -1
at com.wles.arme.Credentials_ca.exceptionTransport(Credentials_ca.java:6
06)
at com.wles.arme.Credentials_ca._accessAllowed(Credentials_ca.java:343)
at com.wles.arme.CredentialsImpl._accessAllowed(CredentialsImpl.java:398
)
at com.wles.arme.CachingCredentialsImpl._accessAllowed(CachingCredential
sImpl.java:264)
at com.wles.arme.CredentialsImpl.accessAllowed(CredentialsImpl.java:435)
at com.wles.arme.CachingCredentialsImpl.accessAllowed(CachingCredentials
Impl.java:52)
at com.bea.security.providers.authorization.asi.AuthorizationProviderImp
l.ARMEisAccessAllowed(AuthorizationProviderImpl.java:869)
at com.bea.security.providers.authorization.asi.AuthorizationProviderImp
l.isAccessAllowed(AuthorizationProviderImpl.java:331)
at com.bea.security.ssal.micro.MicroAuthorizationManagerWrapper.isAccess
Allowed(MicroAuthorizationManagerWrapper.java:73)
at com.bea.security.ssmrmi.services.impl.RMIAuthorizationServiceImpl.isA
ccessAllowed(RMIAuthorizationServiceImpl.java:179)
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:160)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:5
35)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTranspor
t.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport
.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:909)
at java.lang.Thread.run(Thread.java:662)
This closely resembles a known issue. Can you please contact Oracle support for a fix.
Thanks,
Subbu Devulapalli
[…] how to create basic OES policy objects which were covered in Hello OES World. The note I provided earlier about requiring patch also applies to this blog […]
Thanks Subbu for all your post, you are helping me a lot. I am trying to migrate some policies from 10g to 11g and I am getting this error when I am trying to test a policy with an attribute on the condition. I am testing it with your JSP app (blog-oes-wls-sample.ear). This is the error:
Feb 14, 2012 9:36:18 AM com.bea.security.providers.authorization.asi.AuthorizationProviderImpl isAccessAllowed
SEVERE: Error happens: ArmeRUNTIME Exception: unable to parse type of the decl l, type kind = -1
Feb 14, 2012 9:36:18 AM com.bea.security.ssal.micro.MicroAuthorizationManagerWrapper isAccessAllowed
SEVERE: The exception has been thrown by ARME. The authorization result is set to deny.
com.bea.security.providers.authorization.asi.InvocationException: ArmeRUNTIME Exception: unable to parse type of the decl l, type kind = -1
at com.bea.security.providers.authorization.asi.AuthorizationProviderImpl.isAccessAllowed(AuthorizationProviderImpl.java:380)
at com.bea.security.ssal.micro.MicroAuthorizationManagerWrapper.isAccessAllowed(MicroAuthorizationManagerWrapper.java:73)
at com.bea.security.impl.AuthorizationServiceImpl.isAccessAllowed(AuthorizationServiceImpl.java:823)
at com.bea.security.impl.AuthorizationServiceImpl.isAccessAllowedInternal(AuthorizationServiceImpl.java:1531)
at com.bea.security.impl.AuthorizationServiceImpl.isAccessAllowed(AuthorizationServiceImpl.java:1471)
at com.bea.security.AuthorizationService.isAccessAllowed(AuthorizationService.java:526)
at oracle.security.jps.openaz.pep.PepRequestImpl.processDecide(PepRequestImpl.java:144)
at oracle.security.jps.openaz.pep.PepRequestImpl.decide(PepRequestImpl.java:125)
at jsp_servlet.__authzresponse._jspService(__authzresponse.java:147)
Do you know could be the problem?
Thanks,
Leandro.
OES 10g policies cannot be migrated to OES 11g. There will be a future release of OES which will include tooling to migrate policies from OES 10g to the new release.
Bye,
Subbu Devulapalli
Jagan,
OES relies extensively on standards. This helps OES integrate with products from competing companies.
For example in JEE/JSE ecosystems, you can use authenticated JAAS subject to propagate identity from authentication service to OES (authorization service). So in JEE/JSE env. you can rely any authentication service which supports JAAS (Java Authentication and Authorization Service Standard).
OES supports LDAP v2/v3 standard which allows you to wire OES to pretty much any LDAP in the market. This will allow you to define authorization policies based on identity attributes.
For DB, OES support JDBC which is supported by all DB vendors
Bye,
Subbu Devulapalli
I have policy like if (String_at_least_member_of(value1, listOfValues))
Now in attribute retriever I have written code and for attributes for value1 and listOfValues and it is hitting database and getting values. Till this point I am good.
Now with the policy “if (String_at_least_member_of(value1, listOfValues))” I need to return some values as obligations. Obligations are figured out based on matched values found in value1 and listOfValues.
My question is : Is it possible to set matched values from String_at_least_member_of(value1, listOfValues) in some attribute so that it can be retrieved in attribute retriever PIP logic? Otherwise I need to fetch value1 attribute first and then I need to fetch listOfValues attribute , and then I need to run a loop to figure out matching values between the two. This will be rework and that is what I don’t want to do. Please help
Appreciate your effort. Thank You.