We are using seafile with a “Single Sign-On” authentication based on OIDC in keycloak.
It works well to connect to the interface through the client.
But is there a way to reach the differents API endpoint with the bearer token provided by the OIDC provider ( here keycloak but it’s standard token ) ?
For exemple use the bearer directly in the call of the API. Or at least use the bearer in a specific endpoint like api2/auth-token/ to get a seafile token.
edit : same problem and same question about how to use webdav with SSO.
I’m also intersted in this implementation (API and WebDav through SSO)
We are planning to give access to seafile from a portal on which authentication could be based on Shibboleth / Apache HTTP Remote Host / OIDC, from LemonLdap::NG SSO provider (similar to keycloack)
@daniel.pan@Jonathan,
If we delegate SSO authentication from local Shibboleth SP (one the same machine as Seafile) to Lemonldap SSO (on a central SSO endpoint), could we use WebDav and API ?
This is a required feature for us. I’m working on an implementation for the 6.3 branch. Any interest in a pull request?
For info, I’m working for the Human Brain Project (an EU Horizon 2020 project) and we’re working on rolling out a collaborative research and teaching platform for neuroscientists. We’ve picked seafile for the shared storage backend, and we’re integrating it with Jupyter Lab, KeyCloak and XWiki. We’re on the CE for now and evaluating whether we will get the pro version.
Note this thread: Authenticate to seafile APIs using Shibboleth, where daniel.pan sketched a way to access the API with Shibboleth. The same is possible with OIDC. However, OIDC does not have a specific success page in Seafile. Seafile’s OIDC callback (the page called by Keycloak upon successful login) is at /oauth/callback, and it displays your list of libraries (the usual Seafile home page).
One option is to include the below patch (based on 6.3.4) in seahub/seahub/templates/libraries.html. However, this is dangerous if you do not understand it! Make sure to set a very specific allowed origin in postMessage, because otherwise any site you open in your browser can steal your access token – simply by opening a new window with your Seafile instance while you are logged in.
--- libraries.html 2019-04-16 17:33:50.652115255 +0200
+++ libraries.html.modified 2019-04-16 17:33:00.622745013 +0200
@@ -313,6 +313,36 @@
freezeItemHightlight: false
};
</script>
+
+<script>
+(function() {
+function getCookie(name) {
+ var cookieValue = null;
+ if (document.cookie && document.cookie != '') {
+ var cookies = document.cookie.split(';');
+ for (var i = 0; i < cookies.length; i++) {
+ var cookie = cookies[i].trim();
+ // Does this cookie string begin with the name we want?
+ if (cookie.substring(0, name.length + 1) == (name + '=')) {
+ cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
+ break;
+ }
+ }
+ }
+ return cookieValue;
+}
+
+let seahub_auth_info = getCookie("seahub_auth");
+
+if (seahub_auth_info) {
+ window.parent.postMessage(seahub_auth_info, "https://www.example.com");
+ if (window.opener) {
+ window.opener.postMessage(seahub_auth_info, "https://www.example.com");
+ }
+}
+})();
+</script>
+
{% if debug %}
<script data-main="{% static "scripts/main.js" %}" src="{% static "scripts/lib/require.js" %}"></script>
{% else %}
A “portal page” could then do something like this:
Thanks for the work. It can achieve the goal of display a user’s information in “portal” page.
But I’m afraid we can’t merge the PR. As this is dangerous and most customers may don’t understand it, if it turned on by default, it may cause a security hole.
If so, you can use the code showed by @MJochim to open an invisible frame in the browser to login via SSO and get the token, then get the token from the invisible frame via postMessage.