OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml] REST Profile wd04 - Security


> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On
> Behalf Of Mr. Jean-Paul Buu-Sao
> Sent: Wednesday, May 23, 2012 5:07 PM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] REST Profile wd04 - Security
> I have added some suggested additions around <<...>> markers below:
> [...] This section describes some additional considerations that have
> to do with the networked nature of a RESTful architecture<<, together
> with the administrative capabilities setout by this profile>>
> 3.2 Authentication
> HTTP status code 401 (Unauthorized) [HTTP] MAY be used to indicate that
> an operation on a resource is denied because the <<requestor>> is not
> authenticated
> Note: replaced user by requestor because the profile is likely to be
> used by non-human users as well

Yes, good one.

> Authentication means: You can mention Digest authentication, but then
> other mechanisms should be mentioned as well, in a non normative way.
> Example: federated authentication via SAML token

The current text contains the following:
"Additional standards like [OpenID], [SAMLv2] or [SASL] MAY be used instead of or in addition to HTTP Digest authentication."

Is that not what you're looking for?

> 3.3 Authorization
> I suggest to add something along the lines: <<Implementations can
> perform authorization based upon the identity of the requestor, as well
> as on any appropriate additional, trusted, attribute>> (hence the
> importance of mentioning federation above)
> "This specification RECOMMENDS that authorization be implemented using
> XACML" is a correct statement but still is too vague. I suggest that
> you have a specific section on constrained delegation that the
> implementations must support, in order to authorize appropriate
> administrative actions (such as: delete all versions of a policy set,
> to your example).
> The REST profile does not need to mandate constrained delegation, but
> this model IMO should be recommended on all PAP actions

I'll add something to that extent.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]