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

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

Rich.Levinson wrote:
> 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.
>          o 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.
>>
>>   
>

fine-grain-authorization-intents.ppt