[OASIS Issue Tracker] Commented: (ODATA-301) Guidance around data authorization model and secure authenticated access to an OData Service

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ODATA-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33294#action_33294 ] 

Stefan Drees commented on ODATA-301:
------------------------------------

Well in https://www.oasis-open.org/committees/download.php/48728/odata-meeting-30_on-20130321-minutes.html#odata-301 we noted the discussion w.r.t. the client:
"""
* Stefan does not oppose the proposal, but asks why basic authentication is required for interoperabilty adn if there are use cases (since interoperability might push more insecure solutions).
* Ralf explains, that this is due to every browser can handle basic auth, thus the motivation is more to be interoperable with the majoreity of (browser) clients 
"""
So to summarize I think we said: We do not like basic auth, but, Ok, any browser (corporate patched ones also) can at least support BasicAuth, that is important for us. What I pointed out in the discussion was my concern, that interoperability might add a) the weak basic auth to the portfolio of clients (weakening it!) and b) help erode the will and budget of implementers for adding stronger auth methods to clients and servers alike.

I am willing to help investigate the zoo of authentication approaches in the wild. 
Maybe we find something, that helps bear with a "SHOULD support basic auth" like in "MUST support at least one of the following auth methods: LIST" 
or at least introduce a MUST with a clause stating: "if not forbidden by a policy" (or the like).

I fear, that we can neither keep security aspects really out of our specs nor cope with them in a necessary and sufficient way (without introducing a mess of poor man recipes) but will have to work hard on acceptable working solutions.

> Guidance around data authorization model and secure authenticated access to an OData Service
> --------------------------------------------------------------------------------------------
>
>                 Key: ODATA-301
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-301
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData Protocol 
>    Affects Versions: V4.0_CSD01
>         Environment: [Applied]
>            Reporter: Ralf Handl
>            Assignee: Martin Zurmuehl
>             Fix For: V4.0_CSD02
>
>
> For interoperability it is highly desirable to define common minimum set of authentication methods, e.g. if a service requires authentication, it MUST accept basic authentication over HTTPS in addition to whatever else it chooses.
> For data authorization we give guidance whether the data model may depend on the authenticated user, only the data content. It puts a higher burden on clients if properties or entity sets appear in or disappear from the model depending on the authenticated user, requiring to always first interpret $metadata, or if only the data content depends on it, i.e. entities show up or not, nullable properties appear to be null or contain confidential information.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira