[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: [cloudauthz] a definitino of 'Entitlement' - proposal
Hi Michael On 22/01/2013 18:17, Mike Poulin wrote:
David, it is certrainly to earlier in the process to get to the level of semantics that distingiuishes between the owner and the entitlement system that is supposed to work on its behalf. Nonehteless, based on my experience of working with other standard TCs, I think it is very important to establish an accurate wording from the beginning.
I agree with this This will
save us from the later arguments like "this expressions is used by us from the early days and nobody had problems with it". I do have a problem even at the lower semantic level. Also, in my practice, a wrong implementation of correct business rules was as frequent as mistakes in specifications of business rules. So, I cannot agree that this is an insignificant matter, sorry.
There are multiple steps involved in implementing business rules and errors can be introduced in any of them. I was only referring to the very last step, the correct or faulty operation of a policy engine (PDP). In my opinion it is much more likely that an incorrect policy was entered into the PDP, than the PDP having bugs in it and giving a wrong answer to a correct policy. So I am saying that the wrong implementation of the business rules is the most likely reason for an incorrect decision.
regards David
Best regards, - Michael Poulin----- Original Message ----- From: David Chadwick Sent: 01/22/13 05:46 PM To: Mike Poulin Subject: Re: FW: [cloudauthz] a definitino of 'Entitlement' - proposal Mike i think you are splitting semantics to too fine a point. If the owner sets the policy for the entitlement system and the latter obeys the owner's policy then the owner is effectively making the decision, albeit via a piece of automated machinery that acts on his behalf. The chance of the entitlement system making a "wrong" decision due to a fault in its machinery is far less than a wrong decision due to the owner not specifying his policy accurately enough. So I think the risk you talk about is insignificant compared to the risk of the owner screwing up himself. Complex policies are very hard to get right regards David On 22/01/2013 15:54, Mike Poulin wrote: > I think we have to use more accurate language - if an entitlement system > make actual decision about permission, it is done NOT by the owner of > the resource. However, entitlement system acts upon > instructions/directives given by the owner. So, the decision belongs to > the entitleement system, in general, not to the owner of the resourse, > and the entitleement system has a risk of realising the owner's > instructions/directives not in 100%. This what we must to take into > consideration. > > I think that the industry passed the point of the owner making > entilement decisions long ago. > > - Michael Poulin > >> ----- Original Message ----- >> >> From: David Chadwick >> >> Sent: 01/22/13 02:46 PM >> >> To: Barbir, Abbie >> >> Subject: Re: FW: [cloudauthz] a definitino of 'Entitlement' - proposal >> >> >> >> Tom, I think we are on the same path. What we call the entity that >> passes from the user to the resource is less important than its >> semantics, and we agree it is not a privilege, but rather it is >> something that the resource owner decides is or is not permission to >> access what the user requested to access. I dont think entitlement is >> the correct name for this entity >> >> regards >> >> David >> >> On 22/01/2013 14:18, Barbir, Abbie wrote: >> > *From:*Smith, Thomas C. [mailto:Tom.Smith@jhuapl.edu] >> > *Sent:* Tuesday, January 22, 2013 9:07 AM >> > *To:* Barbir, Abbie >> > *Subject:* RE: [cloudauthz] a definitino of 'Entitlement' - proposal >> > >> > Abbie, >> > >> > I tried to post this but it bounced. Can you post it for me? Thanks, -tom >> > >> > All, >> > >> > So here’s my two cents… >> > >> > An entitlement is what you get by virtue of membership regardless of how >> > it’s obtained (birth, grant, activity, etc.). It implies, but does not >> > guarantee or even specify privilege (where privilege is allowing a >> > subject’s requested resource action in a given context). To say it >> > another way, privilege is the consequence of applying policy to >> > entitlement(s). This separation of concerns is very important because >> > the resource owner controls the policy, not the entitlement manager. So >> > if you bind them in the design then it will not scale across resource >> > owners that don’t have the same policy set. >> > >> > -tom >> > >> > *From:*cloudauthz@lists.oasis-open.org >> > <mailto:cloudauthz@lists.oasis-open.org> >> > [mailto:cloudauthz@lists.oasis-open.org] *On Behalf Of *Mike Poulin >> > *Sent:* Tuesday, January 22, 2013 8:12 AM >> > *To:* cloudauthz@lists.oasis-open.org >> > <mailto:cloudauthz@lists.oasis-open.org> >> > *Subject:* [cloudauthz] a definitino of 'Entitlement' - proposal >> > >> > Hello All, >> > here is a proposal for a definitino of Entitlement: >> > >> > An Entitlement is >> > >> > * ·A concept of having a right to something or a guarantee of access >> > to something or based on established rights or by legislation. A >> > "right" is itself an entitlement associated with a moral or social >> > principle, such that an "entitlement" is a provision made in >> > accordance with the legal framework of a society. >> > * ·A process of on- and off-boarding an entitlement system, claiming >> > and assigning access rights, and administering the entitlement system >> > * ·A system (manual or automated) that physically realises the >> > entitlement process, keeps entitlement entries, maintains >> > permissions and access rights for as well as information about the >> > actors and resources covered by the entitlement >> > >> > >> > >> > Cheers, >> > - Michael Poulin >> > >> > ------------------------------------------------------------------------ >> > This message, and any attachments, is for the intended recipient(s) >> > only, may contain information that is privileged, confidential and/or >> > proprietary and subject to important terms and conditions available at >> > http://www.bankofamerica.com/emaildisclaimer. If you are not the >> > intended recipient, please delete this message. >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]