[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Requirement for Isolated Request for Authorization Atributes
Subject: RE: Requirement for Isolated Request for Authorization Atributes > From: Orchard, David [mailto:dorchard@jamcracker.com] > Pardon my gross ignorance, but is requesting authorization attributes > roughly equivalent to requesting policies? So would it be > that SAML defines > a carrier for whatever XACL defines for ACLs? > > Dave There is a point at which the one can become the other. Trying to make hard and fast definitions as to the category of a particular assertion may be a mistake since in many cases the distinction lies in the level of abstraction rather than an objective issue. Take it by cases, "Alice is authorized to access the file xyz.html" In scope "Alice has the rights identifier PQR" In scope (although see discussion on roles) "Any party with the rights identifier PQR is authorized to access the file xyz.html" Appears to be in scope but is very definitely a policy statement "Access to the file PQR is governed by this ACL" Out of scope, where we don't want to go... The distinction then becomes even more blurred if one considers that a more likely ACL statement would be "Holdership of this rights identifier is governed by this ACL" This follows from a repeated suggestion by Butler Lampson that ACLs should not be bound to resources since in almost every case an ACL is shared across many resources. I am using the term rights identifier here since the term is empircally defined in the VMS O/S. I have seen the term role used in two contexts, first as a marketeese term for 'rights identifier', second as a rights identifier that can be enabled or disabled at will by the user, in most cases on presentation of additional authentication data. Rather than state 'we don't want to define policy' I think we should state 'we don't want to define a policy language'. I believe that that statement makes clear the implementation complexity threshold we do not want to cross. However it does again point to the need for a re-usable assertion framework since it would be very useful if the wrapper of an ACL could be parsed by the same parser as an SAML assertion. For example from a discussion document I just sent to the core list as an example of what we don't want to do but the type of data a PDP might require as input [I will forward the document to the full list as soon as I have gone through the use case draft to work out the correspondences] <TASS-ACL> <AssertionID>http://policy.carol.test/assertion/ <Issuer>URN:dns-date:policy.carol.test:2001-03-03:1204 <ValidityInterval> <NotBefore> <NotOnOrAfter> <Resources> <string>http://store.carol.test/finance <ACL> <ACE> <Subject> <Right>URN:dns-date:www.bizexchange.test:2001-01-04:right:finance <Permit>RWED <ACE> <Deny>ED <Subject> <Right>URN:dns-date:www.bizexchange.test:2001-01-04:right:ops <Permit>R <ACE> ... Phillip Hallam-Baker Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > > > -----Original Message----- > > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] > > Sent: Monday, March 12, 2001 7:19 AM > > To: 'security-use@lists.oasis-open.org'; > > 'security-core@lists.oasis-open.org' > > Subject: Requirement for Isolated Request for Authorization > Atributes > > > > > > In last week's Core Assertions concall there was some > > discussion about the > > idea of requesting Authorization Attributes for a user who is > > not currently > > logged in. I have a recollection of someone on a Use Case > > concall a few > > weeks ago saying this was an important requirement. > > Unfortunately I do not > > remember who it was. It was pointed out that the current use > > cases do not > > contain this element. > > > > Obviously a request of this type could be used as a performance > > optimization, but does someone have another scenario in mind? > > I hope no one > > is planning to use SAML for provisioning. Based on current > > thinking, I don't > > think this will work. > > > > As I was writing this, I realized that perhaps what was > intended was a > > business transaction scenario, for example: UC-2-08:ebXML, > > currently in the > > issues list. In this case, the PDP may retrieve the > > Authorization Attributes > > after having received an ebXML message from the user. > > > > Are there any other use cases which involve the request of > > Authorization > > Attributes when an Authentication Assertion has not > > previously been issued? > > > > Hal > > > > > > > > ------------------------------------------------------------------ > > To unsubscribe from this elist send a message with the single word > > "unsubscribe" in the body to: > > security-use-request@lists.oasis-open.org > > > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: > security-use-request@lists.oasis-open.org >
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC