Convener: Peter Gietz
Abstract: Within the DARIAH project the Non-Web SSO use case of accessing data on the distributed storage needs to be solved. The proposed flow starts with the user authenticating via her browser to a web application(in this case the user interface of the DARIAH repository), using the standard SAML Web-SSO flow.The DARIAH repository stores data and reads data through Rest API and the problem was to enforce the access rools, like member of a particular group is allowed to read a particular file, on this level. As solution the existing PDP shall be integrated with an OAuth2 AS. The architecture was discussed positively and it was identified that in the last part of the flow (the REST API Implementation asks the AS to verify the token) has been standardized very recently in oAuth2, see RFC 7662.
Tags: Non-Web SSH, Oauth2, SAML
Slides:
Notes:
A Policy Decision Point (PDP) is a good thing if you have complex rules for access decisions, so that the application (the Policy Enforcement Point, PEP) does not need to evaluate such rules.
Within the DARIAH project we want to have access to the storage where there is no user on the browser (Non-Web-SSO). The flow starts with the user authenticating via his browser to a web application (in this case the user interface to the DARIAH repository, using the standard SAML Web-SSO flow.
The user interacts with the DARIAH repository and the DARIAH repository stores data and reads data through rest API and the problem was to enforce the access rolls, like member of group x is allowed to read file z.
The PDP integrated with an OAuth2 AS is where the access decision is made.
We experimented with integrating OAuth2 into a SAML based federation, and we had an RBAC standard based decision point that can take care of access control, access control on single files. The idea was to get this info about the access control to the DARIAH Storage API via OAuth2 that only gives out tokens after checking with the PDP system whether the users are allowed to or not. The question for this Session is: are we sort of misusing OAuth2 where generally the user will be asked to authorize a token and now we use the PDP instead. What do you think about this, or are we misusing the OAuth2.
The Rest APIs don’t support SAML, and the SAML token security profile is not used, except in a few communities. The rest of the world is looking into OAuth2 tokens and we decided to go with the OAuth2, using SAML instead of Open ID connect.
Charis: Do you label your information, if you give a token back that means that someone has the access to the storage then you risk to allow anyone to rewrite every file. The basic idea is that you must give a different token with a different scope every time and the storage must be able to interpret that unless you send the token to the PDP in an XACML style request (Subject, object, action) get the result to permit or deny access.
Convener: The storage API knows from the repository software that the user x (who) wants to read (how) the file y (what). RBAC system will be deciding and normally the RBAC will say yes or no and the storage API will do it with a privileged account. Now the API will only get an OAuth2 token(in the HTTP header) and will access the Storage-infrastructure (irods federation) with this token in the name of the user after checking the validity at the OAuth2 AS, as a one time decision and every access you will get a new authorisation token.
Radovan: The interaction in step 7 (Token validation) is not standardized?
A: There is no standardization in the 7. The current implementation of the Storage API will be enhanced with the OAuth2 (Token in HTTP header), thus the actual API will not be changed.
Convener: 1 and 2 is SAML authentication, 3 is the basic question is sent if the user is allowed to access file x or y and this is the SAML protocol question and the response is an OAuth2 token presented in 4, if the user has the access and the 6 is an HTTP with the token and the 7 you mentioned is the API is to validate the token if the token is valid and the token validation is a part of the OAuth2 protocol.
Charis: In 3, you are using the userID as a scope?
The user has a particular role (separation of duties), at one point of time the user selects the role in which he wants to act.
So the user ID is a role ID?
A session connected to a specific role.
Albrecht: Were the storage API modified?
It’s a design phase only so input is needed and the storage API exists which is a simple HTTP rest API and by now every access decision has to be done on the repository level and what we want to do is to have the access decision at the DARIAH Storage API.
Albrecht: Is it the interactive session with the user?
The interactivity with the user is only at the beginning of the Session (Web-SSO) but then the repository will have the notion of the user and with it will get the access possibilities of the user.
The step 7 is actually not standardized in the end. But the UMA standard has this kind of strategy. OAuth2 is not a protocol is a protocol framework.
Albrecht: The OAuth2 might not be good in the long-term track though?
The entity points of the API will stay the same and the functionality will too but that we only demand in the http header the implementation of OAuth2. It could potentially also be working with the SAML security token.
The only thing is that all of the components need to be in a trust framework so that DARIAH has to trust the federation the SAML federation and also has to trust the combined PDP/OAuth2 server.
Albrecht: How distributed is your architecture?
The idea is to have as many of these building blocks that are distributed, we will have lots of instances of the storage API (at every computer centre involved), Also the repository is designed to be distributed, but the meta data management has to be on one place and highly available but there has to be one sort of master index somewhere. The PDP can also be distributed, since the policy information point will be an LDAP server that contains the data so there we will be many instances of that.
Charis: So you are building a federated object storage?
The problem will be the storage of tokens as long as they are valid. Yes of course the tokens will be the stored in the RBAC+OAuth2 and they will be deleted if they are not validated. The time of how long the tokens are valid is a matter of minutes.
Albrecht: I believe the minutes are not a long time to live - is this an issue?
It is not about the clock of the computers of the servers API but the OAuth2 have to have the same time. LDAP is used for storing the information about the sessions, about the roles and the OAuth2 tokens. The time issue is about storing the tokens and if the tokens are held up there might be some performance issues, if there are such issues we will just store them in another database.
Step 7 is just the validation of the OAuth2 token if the token is still valid and if the token is validated by the authority in the first place.
