OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Groups - REST Profile of XACML v3.0 Version 1.0, working draft 05 uploaded

    Posted 05-31-2012 22:40
    Submitter's message Changes:
    - PDP is now optional, allowing PAP-only servers
    - Added explanatory text for delete example
    - Added note on policies contained within policy sets
    - Added note that supplied policies must be valid according to the policy schema
    - Improved wording in Security section
    - Added ?lost? paragraph from WD02 about the contents of the entry point resource
    - Added text on different types of PAPs
    - Added text on policy (version) equality
    - Added use of HTTP to conformance section -- Mr. Remon Sinnema Document Name : REST Profile of XACML v3.0 Version 1.0, working draft 05 No description provided. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2012-05-31 15:39:48


  • 2.  PDP Issuers re: REST Profile working draft 05

    Posted 06-28-2012 15:30
    I will comment on the PDP issues here and the PAP issues separately.   My two original comments have not been addressed.   Use of <Request> element vs. the <XACMLAuthzDecisionQuery> element.   Request/response correlation.   I propose the following solutions.   State explicitly that the XACML request type can include either <Request> for XACML core or <XACMLAuthzDecisionQuery> from the SAML Profile. Include normative references to each and state that the processing and response must be as specified in the respective specification. State that when <Request>  is used, the additional functionality is not available.   State that when <XACMLAuthzDecisionQuery> is used, requests and responses can be correlated using Request Id and InResponseTo. State that when <Request> is used the PEP must not send a request until the response from a previous response has been received.   Hal       From: Remon Sinnema [mailto:remon.sinnema@emc.com] Sent: Thursday, May 31, 2012 6:40 PM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 05 uploaded   Submitter's message Changes: - PDP is now optional, allowing PAP-only servers - Added explanatory text for delete example - Added note on policies contained within policy sets - Added note that supplied policies must be valid according to the policy schema - Improved wording in Security section - Added “lost” paragraph from WD02 about the contents of the entry point resource - Added text on different types of PAPs - Added text on policy (version) equality - Added use of HTTP to conformance section -- Mr. Remon Sinnema Document Name : REST Profile of XACML v3.0 Version 1.0, working draft 05 No description provided. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2012-05-31 15:39:48  


  • 3.  RE: [xacml] PDP Issuers re: REST Profile working draft 05

    Posted 06-28-2012 20:05
    >> State that when <XACMLAuthzDecisionQuery> is used, requests and responses can be correlated using Request Id and InResponseTo. State that when <Request> is used the PEP must not send a request until the response from a previous response has been received.   Can we constrain this to “within the same network connection”?  If a client makes multiple connections to the PDP server and issues one request per connection, there should be no ambiguity on the server of which response goes with which request because processing of each request should be handled within the context of the connection. And there should be no ambiguity on the client because it is issuing only one request per connection, and the response comes back on the same connection the request was issued on. Right?   -Danny   Danny Thorpe Product Architect Quest Software - Now including the people and products of BiTKOO www.quest.com   From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Hal Lockhart Sent: Thursday, June 28, 2012 8:30 AM To: Remon Sinnema; xacml@lists.oasis-open.org Subject: [xacml] PDP Issuers re: REST Profile working draft 05   I will comment on the PDP issues here and the PAP issues separately.   My two original comments have not been addressed.   Use of <Request> element vs. the <XACMLAuthzDecisionQuery> element.   Request/response correlation.   I propose the following solutions.   State explicitly that the XACML request type can include either <Request> for XACML core or <XACMLAuthzDecisionQuery> from the SAML Profile. Include normative references to each and state that the processing and response must be as specified in the respective specification. State that when <Request>  is used, the additional functionality is not available.   State that when <XACMLAuthzDecisionQuery> is used, requests and responses can be correlated using Request Id and InResponseTo. State that when <Request> is used the PEP must not send a request until the response from a previous response has been received.   Hal         From: Remon Sinnema [mailto:remon.sinnema@emc.com] Sent: Thursday, May 31, 2012 6:40 PM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 05 uploaded   Submitter's message Changes: - PDP is now optional, allowing PAP-only servers - Added explanatory text for delete example - Added note on policies contained within policy sets - Added note that supplied policies must be valid according to the policy schema - Improved wording in Security section - Added “lost” paragraph from WD02 about the contents of the entry point resource - Added text on different types of PAPs - Added text on policy (version) equality - Added use of HTTP to conformance section -- Mr. Remon Sinnema Document Name : REST Profile of XACML v3.0 Version 1.0, working draft 05 No description provided. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2012-05-31 15:39:48  


  • 4.  RE: [xacml] PDP Issuers re: REST Profile working draft 05

    Posted 06-28-2012 21:49
    I would state it as “per TCP/IP session”. But I agree. I am not sure managing a session pool is simpler, but you proposal will work.   Hal   From: Danny Thorpe [mailto:Danny.Thorpe@quest.com] Sent: Thursday, June 28, 2012 4:05 PM To: Hal Lockhart; Remon Sinnema; xacml@lists.oasis-open.org Subject: RE: [xacml] PDP Issuers re: REST Profile working draft 05   >> State that when <XACMLAuthzDecisionQuery> is used, requests and responses can be correlated using Request Id and InResponseTo. State that when <Request> is used the PEP must not send a request until the response from a previous response has been received.   Can we constrain this to “within the same network connection”?  If a client makes multiple connections to the PDP server and issues one request per connection, there should be no ambiguity on the server of which response goes with which request because processing of each request should be handled within the context of the connection. And there should be no ambiguity on the client because it is issuing only one request per connection, and the response comes back on the same connection the request was issued on. Right?   -Danny   Danny Thorpe Product Architect Quest Software - Now including the people and products of BiTKOO www.quest.com   From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Hal Lockhart Sent: Thursday, June 28, 2012 8:30 AM To: Remon Sinnema; xacml@lists.oasis-open.org Subject: [xacml] PDP Issuers re: REST Profile working draft 05   I will comment on the PDP issues here and the PAP issues separately.   My two original comments have not been addressed.   Use of <Request> element vs. the <XACMLAuthzDecisionQuery> element.   Request/response correlation.   I propose the following solutions.   State explicitly that the XACML request type can include either <Request> for XACML core or <XACMLAuthzDecisionQuery> from the SAML Profile. Include normative references to each and state that the processing and response must be as specified in the respective specification. State that when <Request>  is used, the additional functionality is not available.   State that when <XACMLAuthzDecisionQuery> is used, requests and responses can be correlated using Request Id and InResponseTo. State that when <Request> is used the PEP must not send a request until the response from a previous response has been received.   Hal         From: Remon Sinnema [mailto:remon.sinnema@emc.com] Sent: Thursday, May 31, 2012 6:40 PM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 05 uploaded   Submitter's message Changes: - PDP is now optional, allowing PAP-only servers - Added explanatory text for delete example - Added note on policies contained within policy sets - Added note that supplied policies must be valid according to the policy schema - Improved wording in Security section - Added “lost” paragraph from WD02 about the contents of the entry point resource - Added text on different types of PAPs - Added text on policy (version) equality - Added use of HTTP to conformance section -- Mr. Remon Sinnema Document Name : REST Profile of XACML v3.0 Version 1.0, working draft 05 No description provided. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2012-05-31 15:39:48  


  • 5.  RE: [xacml] PDP Issuers re: REST Profile working draft 05

    Posted 06-28-2012 21:56
    “per TCP/IP session” is fine with me.  Thanks.   I was concerned with the original wording for the case where there are multiple independent PEPs running in the same process.  (Not an ideal design, but could happen as a result of composing multiple largish subsystems together under one roof). This scenario would likely violate the original wording, and it could be difficult to force them all to serialize access to the PDP.  With the per session wording, as long as each player has their own connection, they continue to operate independently of each other.   -Danny   Danny Thorpe Product Architect Quest Software - Now including the people and products of BiTKOO www.quest.com   From: Hal Lockhart [mailto:hal.lockhart@oracle.com] Sent: Thursday, June 28, 2012 2:49 PM To: Danny Thorpe; Remon Sinnema; xacml@lists.oasis-open.org Subject: RE: [xacml] PDP Issuers re: REST Profile working draft 05   I would state it as “per TCP/IP session”. But I agree. I am not sure managing a session pool is simpler, but you proposal will work.   Hal   From: Danny Thorpe [mailto:Danny.Thorpe@quest.com] Sent: Thursday, June 28, 2012 4:05 PM To: Hal Lockhart; Remon Sinnema; xacml@lists.oasis-open.org Subject: RE: [xacml] PDP Issuers re: REST Profile working draft 05   >> State that when <XACMLAuthzDecisionQuery> is used, requests and responses can be correlated using Request Id and InResponseTo. State that when <Request> is used the PEP must not send a request until the response from a previous response has been received.   Can we constrain this to “within the same network connection”?  If a client makes multiple connections to the PDP server and issues one request per connection, there should be no ambiguity on the server of which response goes with which request because processing of each request should be handled within the context of the connection. And there should be no ambiguity on the client because it is issuing only one request per connection, and the response comes back on the same connection the request was issued on. Right?   -Danny   Danny Thorpe Product Architect Quest Software - Now including the people and products of BiTKOO www.quest.com   From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Hal Lockhart Sent: Thursday, June 28, 2012 8:30 AM To: Remon Sinnema; xacml@lists.oasis-open.org Subject: [xacml] PDP Issuers re: REST Profile working draft 05   I will comment on the PDP issues here and the PAP issues separately.   My two original comments have not been addressed.   Use of <Request> element vs. the <XACMLAuthzDecisionQuery> element.   Request/response correlation.   I propose the following solutions.   State explicitly that the XACML request type can include either <Request> for XACML core or <XACMLAuthzDecisionQuery> from the SAML Profile. Include normative references to each and state that the processing and response must be as specified in the respective specification. State that when <Request>  is used, the additional functionality is not available.   State that when <XACMLAuthzDecisionQuery> is used, requests and responses can be correlated using Request Id and InResponseTo. State that when <Request> is used the PEP must not send a request until the response from a previous response has been received.   Hal         From: Remon Sinnema [mailto:remon.sinnema@emc.com] Sent: Thursday, May 31, 2012 6:40 PM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 05 uploaded   Submitter's message Changes: - PDP is now optional, allowing PAP-only servers - Added explanatory text for delete example - Added note on policies contained within policy sets - Added note that supplied policies must be valid according to the policy schema - Improved wording in Security section - Added “lost” paragraph from WD02 about the contents of the entry point resource - Added text on different types of PAPs - Added text on policy (version) equality - Added use of HTTP to conformance section -- Mr. Remon Sinnema Document Name : REST Profile of XACML v3.0 Version 1.0, working draft 05 No description provided. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2012-05-31 15:39:48  


  • 6.  PAP Issues re: REST Profile working draft 05

    Posted 06-28-2012 15:52
    I think you need to specify that a policy has to be sufficiently well formed to determine what the policy id and version are. The policy does not need to be correct as specified by XACML, because it may be in the process of being edited and debugged.   In section 2.2.3.1, you appear to be using “Cohort” in a way inconsistent with the definition I have proposed. (interchangeable with collection) I don’t object if you want to propose a different definition and get consensus around it, but otherwise I suggest sticking to “collection”.   I am still generally uncomfortable with the amount of variability of the semantics you propose to allow. One cannot tell if a policy change will shut down the system or merely update a file. One cannot tell if requests will succeed or fail because a version has been left out or included.   I am puzzled that there is no way to update a policy in place. It seems like this would be a natural action. Do we have to increment the version just to fix a misspelled word?   Why does delete only delete all versions? What if I just want to get rid of some old versions I am no longer using while keeping the last few?   Since nothing is specified about whether policies are trusted, I wonder if we should allow policies to be wrapped as described in chapter 6 of the SAML profile, so they can be suigned?   Hal   From: Remon Sinnema [mailto:remon.sinnema@emc.com] Sent: Thursday, May 31, 2012 6:40 PM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 05 uploaded   Submitter's message Changes: - PDP is now optional, allowing PAP-only servers - Added explanatory text for delete example - Added note on policies contained within policy sets - Added note that supplied policies must be valid according to the policy schema - Improved wording in Security section - Added “lost” paragraph from WD02 about the contents of the entry point resource - Added text on different types of PAPs - Added text on policy (version) equality - Added use of HTTP to conformance section -- Mr. Remon Sinnema Document Name : REST Profile of XACML v3.0 Version 1.0, working draft 05 No description provided. Download Latest Revision Public Download Link Submitter : Mr. Remon Sinnema Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2012-05-31 15:39:48