(Marcus Hardt)
So far, we have a google doc here: https://docs.google.com/document/d/1ofgSoUXI-CXO5Mqgpm-6bs_cejSdWm_wUAFcsEwbgm8/edit#
Goal is to collect and provide an overview about
M - Marcus
Marcus: In the AARC project one of the next documents is about authorization models for SPs Interested to know which technologies and real life used cases are using them for authorization purposes
The session is being used to edit and add to the google document for the topic: the table of content.
Mischa: Suggestion: Divide in section 2 the components into architecture and technological parts The first three are all about architecture and general models. Where the decision is made and handled. The next ones are technologies to implement that decision. Macaroons are not being developed by google anymore so I think they are discontinued. Also explicitly mention the scope of the document.
Mischa: RFC 2753 is in direct connection to XACML
M: CERN case – considering to move into a token based approach Mischa: We are mixing technology and architecture again. The model implies the architecture – role based or otherwise. M: Use cases in the meaning of different examples how people use different models and reaching a better conclusion Mischa: So for CERN you want to describe the tech or architecture for them? For example Clarin wants the end users to deal with authorization themselves while CERN does the complete opposite – architecturally speaking Moreover MWSCG is looking to change infrastructure and move into different protocols. And if you are a community you should reference to the architecture first then the tech itself.
Agreed to use section 3 in order to reference the described technologies and architecture models described in section 2.
Mischa: Maybe we want to add something related to capability based authorization?
M: Adding it as 2.3i point under 2.3 ACL section
Mischa: If you want to describe the current CERN model it would make sense to describe their current technology infrastructure? The proxy certificate they use. I am adding RFC proxies with VOMS under the technological covers section.
Mischa: Is the Bona Fide researcher being used?
M: The Elixir. HBP team is using it to some extent.
M: What is NIH using at the moment?
Matthew: We are using RBAC by exclusion process to the others. There is a process in action, half automated at the moment. RBAC makes sense for us in terms of a mental model because it specifies exact roles within scientific studies and what actions they can do versus higher or lower role groups. There is a standard set of actors in other techs that do not fulfil that completely. We are also looking at doing something with LoA. Use cases > LoA to implement a digital signature mechanism where you can enter data collection systems with a low level of assurance but In order to be able to make certain actions you would be authenticated again into a new higher level of assurance.
M: Agreed to describe Permissions Matrix and coManage in the document.
Matthew: in our idea of multi factor authentication, is it necessarily very strong? Because that doesn’t make sense with the number of our scientists.
Uros: there are specifications in Loa for that matter too
Matthew: NIH itself I think uses loa4 for its own people / including second factors
M: there is the question which framework you use then to provide assurance etc.
Added into the google document:
M: I am reluctant to add level of assurance.
Peter G: In Elixir it seems that it is a complicated process to assign the exact resources to the right person and I do not see a difference between that and a group membership. The process is about the person being bona fide enough to have access.
Point 4 edited into: Authorization models based on access context 4.1 reedited into – assurance profile based authorization
M: ID provider based filtering is a last resource practically for authorization models. In conclusion there are different models which are not very compatible with each other.
