New OIDC ESCAPE auth driver.

[redblom]

This allows for authentication via the ESCAPE IAM service.
The IAM account group must be mapped to a reva user in a json file where the IAM group name is linked to the reva user through the username.
Example of this file:

[
	{
		"oidc_issuer": "http://iam-login-service:8080/",
		"oidc_group": "Analysis",
		"username": "einstein"
	},
	{
		"oidc_issuer": "http://iam-login-service:8080/",
		"oidc_group": "Sciencemesh",
		"username": "marie"
	}
]

For authentication you must have a valid IAM access token. As an example we can do a login using an access token obtained from the IAM service (use a token tool) and use that as the secret. Leave username empty and use the token as password:

/go/src/github/cs3org/reva # ./cmd/reva/reva -insecure login oidcmapping
username:
password: OK
/go/src/github/cs3org/reva # ./cmd/reva/reva -insecure whoami
id:<idp:"reva-oidc-escape:20080" opaque_id:"4c510ada-c86b-4815-8820-42cdf82c3d51" > username:"einstein" mail:"[email protected]" mail_verified:true display_name:"Test-100 User" groups:"sailing-lovers" groups:"violin-haters" groups:"physics-lovers"

Here the IAM 'Test-100 User' test user is mapped by one of its groups to the reva 'einstein' test user. From hereon you can start sharing etc. as usual.

Regarding mapping:
The IAM user may be a member of multiple groups. If more than one groups are mapped each to a different reva user authentication can not take place because we currently have no mechanism to decide in that case which reva user to use.

[glpatcern]

As discussed I posted a couple of technical comments, and I put here what I mentioned by email:

What was assumed for the integration with ESCAPE for now was higher-level mapping from ESCAPE "groups" to Reva users, rather than a 1-on-1 mapping from ESCAPE "sub" ids to Reva users. The group mapping would allow for a more flexible authorization scheme IMHO, whereas obviously the 1-on-1 mapping allows for a fully fine-grained mapping.

If anything, both could be supported in the code, and then it's up to sites to manage the mapping. The experience with WLCG so far has shown the value of group mapping, following this kind of scheme:

https://github.com/cs3org/reva/pull/2007/files#diff-6d087645b95eec0a67d31be2d060b6af2f44330bd74514756c7dcbcfb81b1456

And even this is to be further developed/thought through because a user may belong to multiple groups, and it is not clear which one of many - potentially conflicting, as in the above example - mappings the system should pick. We could perhaps introduce a priority flag in the above to sort the entries.

[redblom]

Concerning merger of oidc & oidcmapping

I want have something clear: if mapping is unsuccessful, either because no mapping is found or a mapping file is not configured, should we then default to 'bare' oidc ?
Same for errors: if a mapping file IS configured but parsing it fails (file not found or parsing error), should authentication fail or should we default to 'bare' oidc ?

[glpatcern]

I want have something clear: if mapping is unsuccessful, either because no mapping is found or a mapping file is not configured, should we then default to 'bare' oidc ?

This to me is a "user" condition and we should default to bare OIDC.

if a mapping file IS configured but parsing it fails (file not found or parsing error), should authentication fail or should we default to 'bare' oidc ?

This instead is a "service" error, i.e. caused by misconfiguration by the service manager. In that case I would actually fail the init phase so that revad cannot even start.

Makes sense?

[redblom]

Makes sense?

Yes

[glpatcern]

Looks all right to me. As discussed, let's merge (will re-check with Hugo) so we go ahead with tests - this is not touching any production deployment so it's totally safe to merge.