Implementing OAuth provider Dataporten

[xibriz]

A little background information: In Norway, all a lot of public sectors use the a national autentication provider. You may have heard of Feide that integrates with Dataverse today trough Shibboleth. Dataporten is the next gen providing OAuth2 autentication.

I have been working on integrating Dataporten in Dataverse, code here: https://github.com/uit-no/dataverse/tree/dataporten

This will benefit all higher education institusions in Norway. I propose to merge my code so I don't have to maintain a fork.

I can probably provide a test setup with client credentials and guest accounts if that will tip the answer in our favor.

[xibriz]

I have got an GO to set you your test environment up as an application in Dataporten. I just need your Redirect URI and then I can provice you with all nessecary information like Client ID and Secret, test users for login and a dataporten.json file with the userEndpoint

[xibriz]

Since you guys are using ScribeJava I have gotten the DataportenApi as a part of that repository. scribejava/scribejava#805

This means I only have to add 1 new class and a couple of minor changes in my PR that I will be making verry soon.

Also note that to get Dataporten into ScribeJava I had to make arrangement so that the maintainer of ScribeJava could test the code, the same arrangemement will be made for the Dataverse team :)

[djbrooke]

@xibriz thanks for the PR! @scolapasta (Dataverse Architect) and I have a meeting this afternoon and we'll discuss this.

[pdurbin]

Since you guys are using ScribeJava I have gotten the DataportenApi as a part of that repository. scribejava/scribejava#805

@xibriz great! Thanks for adding a comment about this in your pull request, which looks good to me.

[xibriz]

Thanks. Just doing what I can to implement this in the same way you guys have implemented Google and GitHub.

[djbrooke]

@xibriz thanks for the PR! As this is something that’s very specific to Norweigan installations, we don’t want to merge it into develop and include it in a release to the wider Dataverse community. Instead of merging this sort of thing to the Dataverse core code, we are exploring ways to make specific areas of the code modular so that this could be supported in a more sustainable way.

Is making this area of the code more modular something that you are interested in working on? If so, we could work with you to provide initial guidance. Modularity is a new area for us as well, so we’d be interested in learning with you.

[xibriz]

@djbrooke thanks for the info. I need to check with my project leader what he want to do, but I'm interested in how you guys think this should be implemented.

I have some thoughts my self.

For each OAuth2 provider, as I can see, this information is different between them:

• GET/POST
• AccessToken endpoint URL
• Authorization URL
• Scope
• Data format on response JSON/XML/other? and the structure
  and the things you have defined in the authentication provider JSON-file

At the top of my head, I think I have heard of a JSON library that is generic so you can describe which attributes that you want to extract from a structure. If this exist in Java you coud define that the email is in "user->email" for Dataporten and just "email" for Google and so on.

These definitions could be posted to Dataverse trough the same JSON-file as the other stuff along with the other URLs listed.

Then you could have a generic OAuth JSON provider class. Same for XML and other response types.

Just thinking out loud here...

[michbarsinai]

My 2 ¢:
Creating a completely general OAuth2 client would be nice, but OAuth2 is very permissive, so there's a lot of variance between providers. Even ScribeJava ended up writing multiple clients, one-per-service. It may be possible to generalize a bit, though, in the same manner we did with the REST-based workflow step.
Another option is to open the OAuth2 providers as a plug-in area. This way, the Dataporten OAuth2 client will be developed as a plug-in, and so there won't be a need to maintain a fork.

[pdurbin]

Or we could simply merge pull request #4341 so that @xibriz doesn't have to maintain a fork. 😄 Maybe he'll fix other bugs for us too! He already helped with #4336 and is now our 50th contributor! 🎉

Look how quickly he got scribejava/scribejava#805 merged. We are talking about authentication for an entire nation, after all. If we merge the code now, we can factor it out later once we have modularity in place. It isn't even that much code and as @xibriz points out, it will be even less code on the Dataverse side one ScribeJava makes a release that includes his pull request.