Re: [sca-policy] ISSUE 57: Fine grain authorization intent: updatedrequirements

["Rich.Levinson" <rich.levinson@oracle.com>]

This email to update issue 57 for SCA-Policy.

(Note: JIRA not updated w this info, because ... despite the fact that I have tried on at least 3 and probably more like 5+ occasions to get some kind of account on the JIRA system on OSOA, nothing ever seems to happen to make it stick. No idea why; only need to use it infrequently, and whenever I do it just doesn't happen. If someone can give me an email addr where to direct my request, it would be much appreciated.)

Here is some background info on the general use case for fine grain authorization and the need for sca-policy constructs to support it:

The use case is the following:

• A development organization has been directed by management to externalize authorization logic from the body of the application so that it can be instead reside in some form within an external authorization provider.
  
• The developers study the problem and find that there are authorization rules within the application logic that generally consist of some kind of conditional expressions evaluating variables associated with the resource being accessed.
  
• For example, a user accessing their account requests a transaction and may be allowed or disallowed based on some specific conditions that have to do with the current values of properties of the account, such as current balance, days overdue of something that was supposed to happen, etc. etc.
• In the process of modifying the application to remove this logic, the rules associated with the logic are recorded so that they may be included in the rules that are processed by the external authorization provider.
• However, there is a problem: these rules need variable data from the resource in order to be evaluated. Therefore this resource data must be made available to the external authorization provider at the time the request is made to execute the transaction.

While there are a number of issues that need to be addressed in order make the transition to externalized authorization, it is fairly clear that there are at least 2 explicit capabilities that need to be in place:

1. At the point where the external authorization is requested in the application, the data elements needed to evaluate the rules need to be collected and sent to the external authorization provider.
2. The external authorization provider must have the correct policy containing the rules that need to be evaluated, and the external authorization provider must be capable of processing the rules and the associated data which it receives.

From the perspective of SCA-Policy, to further motivate the use case consider the following:

• Assume the application is a high value application and management wants to ensure that it will not be deployed in a configuration where the authorization callouts will be made to an authorization provider that is not capable of handling the rules and the additional data elements that need to be sent.
• Assume there are multiple applications of this sort and that each requires its own designated ruleset (policy) to be processed.

It would appear that the deployment would need to have the following:

1. The deployer would need to be notified by a SCA-Policy intent that a fine grain authorization service needs to be accessed by the application, presumably in a reference element in a "requires" attribute. For example requires="fineGrainAuthorization".
   
2. The deployer of an authorization provider would need to be able to specify that the authorization provider supports fine grain authorization, presumably in a service element in "provides" attribute. For example provides="fineGrainAuthorization".

A second aspect of this is that it is likely that application vendors will provide at least some sample policies that need to be used with their applications. It would be desirable to be able to guarantee at deployment time that all the required policies that were supplied by the application vendor have, in fact, been "installed" with the authorization provider, which, presumably would indicate whatever specific policysets it provides.

One concrete environment where this need currently exists is in J2EE systems where in order to support JSR-115 (JACC), it is necessary to be able to specify a single policy provider that will support a particular JVM runtime. i.e. a JVM runtime can only have one instance of a policy provider operational at any given time.

Not all policy providers are capable of handling data beyond what is provided with the standard J2SE security. In the case of JSR-115, the ability to provide additional data to the policy provider is built-in. However, the policy provider, itself, may or may not be able to process the data that is made available. Therefore, when a particular JVM is having applications deployed, it will need to be determined at that point whether the configured policy provider has the necessary capabilities to support the application external authorization requirements.

The second step in this deployment would be to ensure that any specific policies required by the application were available to the policy provider.





Joshi, Kaanu wrote:

Hi,

A new issue has been created in the SCA Policy TC JIRA. The link to this issue is http://www.osoa.org/jira/browse/POLICY-57.

Please add Rich Levinson's ID to the JIRA. I could not locate his ID and hence have assigned myself as the "Reporter" of this issue.

Regards,
Kaanu Joshi
Expect A Miracle!


-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: Monday, June 30, 2008 7:02 AM
To: OASIS Policy
Subject: [sca-policy] NEW ISSUE: fine grain authorization intent (resend w editing reformatted)

TARGET: SCA Policy spec WD05

DESCRIPTION: at present, section 7.3 only contains
coarse grain authorization configuration capabilities
(role restrictions and authenticated-user restriction).

It is anticipated that application interface points,
in particular, specific operations, will need to be
able to call an authorization service. This would in
a number of ways be analogous to confidentiality
or integrity on messages, except the context would
probably be broader than just the message and include
user context, appl context, and system context as the
scope to which the policy would be applied. (For
example, time of day restrictions, or user must be
manager of the employee whose record is being accessed
restriction, or the usual, user must be over 21 years
old restriction.)

The details of exactly what form this authorization will
take place are not cast in concrete, however one
example is the XACML request response protocol, where the
PEP, which is typically the module that is handling
confidentiality and integrity type services, would also
handle the fine grain authorization services, except later
in the cycle, typically after the operation has actually
been entered and the relevant context available for
collection of the necessary attributes needed to apply
the fine grain authorization rules.

The suggestion at this point is only to provide a hook
for this capability, with the thought in mind that it
might be expanded later. For example, we might have
an intent called "finegrain" and possibly later extend
it to have qualified sub-intents like "finegrain.timeofday"
or "finegrain.mustbemanager", of "finegrain.ageover21check".
It would seem that an appl dev would often be able to
indicate that these kind of authorization checks would
be appropriate to apply, and that a finegrain intent
with specific qualifiers might be a good way to express
these requirements.

PROPOSAL: further discussion then concrete
    proposal if necessary


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete  this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at netadmin@patni.com and delete this mail.