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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

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


Subject: [OASIS Issue Tracker] (OSLCCORE-82) Propose method for access context discovery


    [ https://issues.oasis-open.org/browse/OSLCCORE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=69231#comment-69231 ] 

Andrii Berezovskyi commented on OSLCCORE-82:
--------------------------------------------

Three points from my side:

1) I think while access control is orthogonal to individual resources, the question of correctly inheriting semantics in the TRS Client is paramount, otherwise no enterprise user will allow TRS Clients to fetch resources from their access-controlled systems. 
2) Original AccessContext proposal is here: http://open-services.net/wiki/core/IndexableLinkedDataProvider-2.0/#Access-Context-List-Resource
3) Also see https://issues.oasis-open.org/browse/OSLCCORE-68 for more advanced topic.

Axel, let me expand point 1. Say, there is a Jira installation within a company. We tell them: hey, let's build an REST OSLC adaptor (or a native OSLC Jira plugin, we tried both actually) with a TRS Server capability and allow other apps with TRS Server capability to subscribe to TRS ChangeEvents. Let's say the company buys our interoperability argument. They will say next: we use ACL to limit which user groups can see issues from which Jira projects. Before we let TRS Servers to fetch those issues, we need TRS Server to promise to apply an equivalent ACL to those resources (ie check which group does the user accessing the TRS Server belong to).

This example should demonstrate a need for codifying access control information when we try to copy resources outside their original service.

I think, however, that we are not security folk per se and should not try to reinvent the wheel unless we have a rigorously compiled list of reasons to do so.

I recommend reading the following:

1) https://arxiv.org/pdf/1612.09527.pdf (A recent PhD dissertation on the topic, see p. 41 if you can't be bothered to read it all for a table comparing access control ontologies)
2) https://www.w3.org/wiki/WebAccessControl is a very early W3C effort around this
3) https://github.com/twosixlabs/icas-ontology W3C work was apparently too undeveloped for DARPA, so they published their own ontology

I think we need to thread carefully here and consult people who know their security.

Also, I think it is important to separate authentication from authorisation here. We certainly don't want to tell OSLC servers how to authenticate people but we do want to instruct TRS Servers who is authorised to access the resources they are fetching.

> Propose method for access context discovery
> -------------------------------------------
>
>                 Key: OSLCCORE-82
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-82
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>          Components: TRS
>            Reporter: Martin Sarabura
>            Assignee: James Amsden
>              Labels: TRS
>
> Currently I believe we don't specify how to discover access contexts in our Tracked Resource Specification. We need to fill this gap.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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