How to configure Keycloak as OIDC provider for Linshare #333

kvvloten · 2024-10-30T11:34:01Z

kvvloten
Oct 30, 2024

Hi all,

I am trying to make Keycloak work as OIDC for Linshare, but so far thatis unsuccessful.
Although I am sure I can make it work by using headers (and do the configuration in Apache), that has been marked as deprecated in the documentation. Therefor I am trying to follow the OIDC documentation for Lemonldap and Azure and make the best of it. But no success yet.

I see the calls to Keycloak are happening and successful (according to Keycloak's logs), however the Linshare user frontend returns "SSO authentication failed" while it keeps on showing a spinning wheel.

What is a good approach to debug this?
Or has anybody been able to configure Linshare + Keycloak OIDC successfully?

-- Kees.

wboudiche · 2024-11-04T14:12:33Z

wboudiche
Nov 4, 2024
Maintainer

Hi,
Did you enabled the debug mode in log4j file ?

0 replies

kvvloten · 2024-11-04T21:54:43Z

kvvloten
Nov 4, 2024
Author

I don't think I am getting to the point where there is relevant logging in linshare.log.
It is hard to set it up due to fragmented and (to me) unclear documentation.

Let's go over the setup.

OS on all involved machines is Debian Bookworm.
Linshare version: 6.3
Keycloak version: 25.0.6

Linshare and Keycloak are on different machines and are both behind an Apache reverse-proxy.

The domain office.example.com is accessible internally as well as from the internet. While example.lan is the internal DNS and AD-domain.

Log4j.properties fragment:

property.LOG4J2_APPENDER=LINSHARE
rootLogger=DEBUG, ${LOG4J2_APPENDER}
logger.security = TRACE, ${LOG4J2_APPENDER}
logger.security.name = org.springframework.security
logger.securityldap = TRACE, ${LOG4J2_APPENDER}
logger.securityldap.name = org.springframework.security.ldap
logger.linshareldap = TRACE, ${LOG4J2_APPENDER}
logger.linshareldap.name = org.linagora.linshare.ldap

A fragment of the config of ui-user (config.js):

    oidcEnabled: true,
    oidcForceRedirection: false,
    oidcSetting: {
      authority: 'https://office.example.com/auth/realms/example.lan',
      oidcToken: 'Oidc-Jwt',
      client_id: 'cli_linshare-trusted',
      client_secret: 'the-client-secret',
      scope: 'openid email profile linshare',
      loadUserInfo: false
    },
    mobileOidcEnabled: false,

I left mobile oidc disabled for now, I just want to see it working from a browser first.

According to Keycloak's documentation, it returns a Jwt-token, so I followed sso-microsoft-azure-using-OIDC-JWT-tokens.md to set that bit up, for most other items I used sso-lemonldap-using-OIDC-opaque-tokens.md.

Fragment of linshare.properties:

oidc.on=true
oidc.issuerUri=https://office.example.com/auth/realms/example.lan
oidc.client.id=cli_linshare-trusted
oidc.client.secret=the-client-secret
oidc.access.claim.value="true"
oidc.ldap.connectionUuid=b87a9343-8f8d-4f16-9c3e-d386e6a60af3
oidc.ldap.provider.patternUuid=d541a817-34b1-4803-bcd9-b37ccbb7bfb0

sso-lemonldap-using-OIDC-opaque-tokens.md states: for LinShare >= 5 : Allowed redirection addresses for login: http://linshare-user.local/#!/oidc/callback

This is the first issue! The redirection address is different. Apache on the Linshare host logged this for the redirect performed by Keycloak back to the Linshare application:

GET /oidc/callback?state=e01e701193a94c12a043872304e6f944&session_state=0cfc4ecf-1112-45f6-939b-e46187253a50&iss=https%3A%2F%2Foffice.example.com%2Fauth%2Frealms%2Fexample.lan&code=045680a8-d060-4404-897f-40df8bb291ee.0cfc4ecf-7612-45f6-939b-e46657253a50.d736c258-33df-4f5e-9c78-bd8bcec0a321

The bit /#! is missing !

As a result the /oidc/callback is sent to the java backend instead of the javascript in the frontend.
I worked around it by putting a rewrite in the Apache config:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/oidc/
RewriteRule ^/oidc/(.+) /#!/oidc/$1 [R,L,NE]

This will insert the /#! before continuing and now we have the expected url and it ends up in the frontend's javascript.

This is what Linshared sent to Apache on office.example.com (the Keycloak side):

GET /auth/realms/example.lan/protocol/openid-connect/auth?client_id=cli_linshare-trusted&redirect_uri=https%3A%2F%2Fshare.example.lan%2Foidc%2Fcallback&response_type=code&scope=openid%20email%20profile%20linshare&state=e01e7055693a94c62a043872304e6f944&code_challenge=tQGDDpmTTsl0TCf1LH8ipd5OYF_a7Sj6NozUVqB0sFA&code_challenge_method=S256&response_mode=query

It looks like the missing uri fragment /#! was not sent by Linshare's frontend to Keycloak!

But assuming it had to be there, the rewrite workaround solves it and the token get sent to frontend user-ui.

Unfortunately, it fails there with:

21:13:31.635 Cross-Origin-aanvraag geblokkeerd: de Same Origin Policy staat het lezen van de externe bron op https://office.example.com/auth/realms/example.lan/protocol/openid-connect/token niet toe. (Reden: CORS-header ‘Access-Control-Allow-Origin’ ontbreekt). Statuscode: 200.

21:13:31.635 Error: Network Error [angular.js:15697:40](webpack:///node_modules/angular/angular.js)
    onerror oidc-client.min.js:1
    r Angular
    n oidcCallbackController.js:35

This is visible in browser error-console. The browser windows briefly returns an error saying: SSO authentication failed and then shows a (forever) spinning wheel.

I have not been able yet to figure out how to solve this CORS issue. It is unclear where header ‘Access-Control-Allow-Origin’ should be added. It is easy enough to add a line to one of the reverse proxies to do that. But what I tried so far did not solve anything.

If I remove the rewrite workaround from the config of apache, things get worse: apache log on the Linshare server shows a 404:

"GET /oidc/callback?state=d910f9d0b1964da084793a594ec786cb&session_state=0723ccaa-0450-4a89-95ad-56aad17babf9&iss=https%3A%2F%2Foffice.example.com%2Fauth%2Frealms%2Fexample.lan&code=8b287727-c143-4a45-8d6c-119a3fdc775e.0724ccaa-0360-4a89-95ad-56aad17babf9.d736c258-44df-4f5e-9c78-bd8bcec0a321 HTTP/1.1" 404

And there is more to it: if Linshare would send a redirect url with /#! to Keycloak, then it fails there, because it is not possible to use # in Keycloak in the redirect urls of a client!

Any help is welcome!

What about the uri fragment /#!, is it necessary or not?
What about the user-ui config.js, is it configured correctly?
How to go forward and get a working oidc?

-- Kees.

0 replies

wboudiche · 2024-11-11T18:20:23Z

wboudiche
Nov 11, 2024
Maintainer

Hello,
What about the uri fragment /#!, is it necessary or not? -> Since 6.0.2 the /#! is removed from url.
What about the user-ui config.js, is it configured correctly? it looks good

Did you succeed to get the access token ?

0 replies

kvvloten · 2024-11-11T19:14:29Z

kvvloten
Nov 11, 2024
Author

Unfortunately without the uri fragment /#!, there is nothing that handles the uri, as a result apache returns a 404 (see in my previous message). The java backend reacts to /linshare only (as per documentation), so it will ignore the incoming request at /oidc/callback.
Keycloak authentication is successful (there is a token) and hence it returns /oidc/callback?state=d910f9d0b1964da084793a594ec786cb&session_state=0723ccaa-0450-4a89-95ad-56aad17babf9&iss=https%3A%2F%2Foffice.example.com%2Fauth%2Frealms%2Fexample.lan&code=8b287727-143-4a45-8d6c-119a3fdc775e.0724ccaa-0360-4a89-95ad-56aad17babf9.d736c258-44df-4f5e-9c78-bd8bcec0a321

Fragment of the current apache conf:

RewriteEngine On
# Rewrite to insert /#!
#RewriteCond %{REQUEST_URI} ^/oidc/
#RewriteRule ^/oidc/(.+) /#!/oidc/$1 [R,L,NE]

DocumentRoot /srv/linshare/ui_current/linshare-ui-user

<Directory /srv/linshare/ui_current/linshare-ui-user>
    Require all granted
</Directory>

<Location /linshare>
    Require all granted

    # Workaround to remove httpOnly flag (could also be done with tomcat)
    # Header edit Set-Cookie "(JSESSIONID=.*); Path.*" "$1; Path=/"
    # For https, you should add Secure flag.
    Header edit Set-Cookie "(JSESSIONID=.*); Path.*" "$1; Path=/; Secure"

    # This header is added to avoid the  JSON cache issue on IE.
    Header set Cache-Control "max-age=0,no-cache,no-store"

    ProxyPass http://127.0.0.1:8080/linshare
    ProxyPassReverse http://127.0.0.1:8080/linshare
    ProxyPassReverseCookiePath /linshare /
</Location>

What should be changed to make this work?

-- Kees.

0 replies

wboudiche · 2024-11-14T11:43:59Z

wboudiche
Nov 14, 2024
Maintainer

Hello,

Configuration of Apache LinShare-ui-admin :

<Directory /usr/local/apache2/htdocs/linshare-ui-admin/new>
RewriteEngine on

  RewriteRule  "^(.*)config\.js" "config/config.js"
  RewriteRule  "^(.*)beta\.png" "beta.png"
  RewriteRule  "^(.*)favicon\.ico" "favicon.ico"
  RewriteRule  "^(.*)assets/(.*)" "assets/$2"

  # Don't rewrite files or directories
  RewriteCond %{REQUEST_FILENAME} -f [OR]
  RewriteCond %{REQUEST_FILENAME} -d
  RewriteRule ^ - [L]

  # Rewrite everything else to index.html to allow html5 state links
  RewriteRule ^ index.html [L]
</Directory>

Configuration Apache LinShare-ui-user :

<Directory /usr/local/apache2/htdocs/linshare-ui-user>
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^ index.html [L]

0 replies

wboudiche · 2024-11-21T14:32:25Z

wboudiche
Nov 21, 2024
Maintainer

Hi,
Did you succed to configure it ?

0 replies

kvvloten · 2024-11-21T21:49:51Z

kvvloten
Nov 21, 2024
Author

I am focusing on ui-user first, when that works it is time for ui-admin.

Unfortunately, there is no improvement.

Before I click on the SSO button, I get this in Linshare log:

[TRACE]:http-nio-127.0.0.1-8080-exec-3:20241121.223021:org.springframework.security.web.access.ExceptionTranslationFilter:handleAuthenticationException:Sending to authentication entry point since authentication failed

That looks good, I see it gets redirected to Keycloak and handled there. After it returns to Linshare, I don't get any new logging in linshare.log. But I do get this line in apache log:

192.168.1.106 - - [21/Nov/2024:22:30:46 +0100] "GET /oidc/callback?state=8d94485bdc6346889dad6f19a66d88b7&session_state=d7c207bd-7b96-48e6-be16-f728be5cd3d8&iss=https%3A%2F%2Foffice.example.com%2Fauth%2Frealms%2Fexample.lan&code=571e5be5-2ef9-4e28-b544-1c31dcdec801.d7c207bd-7b96-48e6-be16-f728be5cd3d8.d736c258-33df-4f5e-9c78-bd8bcec0a321 HTTP/1.1" 200 1344 "https://share.example.lan/" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0"

The browser windows briefly returns an error saying: SSO authentication failed and then shows a (forever) spinning wheel:

Fragment of the current apache config:

RewriteEngine On
DocumentRoot /srv/linshare/ui_current/linshare-ui-user

<Directory /srv/linshare/ui_current/linshare-ui-user>
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule ^ index.html [L]

    Require all granted
</Directory>

Alias /upload /srv/linshare/ui_current/linshare-upload-request

<Directory /srv/linshare/ui_current/linshare-upload-request>
    Require all granted
</Directory>

<Location /linshare>
    Require all granted

    # Workaround to remove httpOnly flag (could also be done with tomcat)
    # Header edit Set-Cookie "(JSESSIONID=.*); Path.*" "$1; Path=/"
    # For https, you should add Secure flag.
    Header edit Set-Cookie "(JSESSIONID=.*); Path.*" "$1; Path=/; Secure"

    # This header is added to avoid the  JSON cache issue on IE.
    Header set Cache-Control "max-age=0,no-cache,no-store"

    ProxyPass http://127.0.0.1:8080/linshare
    ProxyPassReverse http://127.0.0.1:8080/linshare
    ProxyPassReverseCookiePath /linshare /
</Location>

0 replies

wboudiche · 2024-12-05T05:25:35Z

wboudiche
Dec 5, 2024
Maintainer

Hi,
can you send ma the content of a generated access token plz ?

0 replies

kvvloten · 2024-12-10T21:01:54Z

kvvloten
Dec 10, 2024
Author

Perhaps we try this first: I have opened the developer interface of the browser. It returns a pretty clear error:

21:52:03.538 Cross-Origin-request blocked: the Same Origin Policy does not allow reading the external source at https://office.example.com/auth/realms/example.lan/protocol/openid-connect/token. (Reason: CORS-header ‘Access-Control-Allow-Origin’ missing). Statuscode: 200.

21:52:03.539 Error: Network Error
    onerror oidc-client.min.js:1
    JsonService oidc-client.min.js:1
    postForm oidc-client.min.js:1
    TokenClient oidc-client.min.js:1
    promise callback*3Rfw/i/</e.prototype.exchangeCode oidc-client.min.js:1
    _processCode oidc-client.min.js:1
    _validateTokens oidc-client.min.js:1
    ResponseValidator oidc-client.min.js:1
    promise callback*3Rfw/i/</e.prototype.validateSigninResponse oidc-client.min.js:1
    OidcClient oidc-client.min.js:1
    promise callback*3Rfw/i/</e.prototype.processSigninResponse oidc-client.min.js:1
    _signinEnd oidc-client.min.js:47
    signinRedirectCallback oidc-client.min.js:47
    signinRedirectCallback oidcService.js:34
    n oidcCallbackController.js:26
    Angular 24
[angular.js:15697:40](webpack:///node_modules/angular/angular.js)

It is correct: linshare lives at share.example.lan and keycloak at office.example.com.

Now the question is how and where to add that CORS-header ‘Access-Control-Allow-Origin’ ?

0 replies

wboudiche · 2025-01-21T08:58:36Z

wboudiche
Jan 21, 2025
Maintainer

Hello,
Normally the OIDC provider manages the CORS by indicating that it's an SPA application (Public application).

0 replies

wboudiche · 2025-02-10T10:53:38Z

wboudiche
Feb 10, 2025
Maintainer

Hello,

Did you succeed to resolve the issue ?

0 replies

kvvloten · 2025-02-12T18:09:38Z

kvvloten
Feb 12, 2025
Author

Can you supply the requirements for the OIDC token, so that I can configure it correctly in Keycloak. I spent quite some time going through the bits and pieces of documentation in de repo but as shown above that did not result in a working setup.
Once I have it working I can share the details of what I did and contribute that to the docs.

0 replies

wboudiche · 2025-02-13T14:54:06Z

wboudiche
Feb 13, 2025
Maintainer

the claims depends on your configuration on LinShare administration/provider but the mandatory ones are :
domain-discriminator
email
first_name
last_name

0 replies

kvvloten · 2025-02-13T19:45:22Z

kvvloten
Feb 13, 2025
Author

I followed the documentation in: https://github.com/linagora/linshare/blob/master/documentation/EN/installation/sso-lemonldap-using-OIDC-opaque-tokens.md and added claims mentioned the admin-portals page /providers/user.

It would be handy to have a good overview all claims, their meaning and allowed content in a single place, for example in the sso-lemonldap-using-OIDC-opaque-tokens.md markdown document.

You write domain-discriminator while it is called domain_discriminator on the admin-portals page /providers/user, which of the two is the right spelling (dash vs. underscore)?

Now that I am checking, it looks like I have some missing claims in the OIDC-token, I will look into that shortly.

But none these changes will likely change the CORS issue. You mentioned it has to be a 'Public application', I will take a look at that too. The markdown also mentions PKCE, is it required or not (I am not setting up access for mobile devices at the moment)?

0 replies

kvvloten · 2025-02-15T20:43:41Z

kvvloten
Feb 15, 2025
Author

I can report progress:

upgrade to 6.4.0 was successful
claims in the token are updated
cors issue is fixed

The good new is that I can login successfully with SSO now!

The access token is:

{
  "exp": 1739649785,
  "iat": 1739649485,
  "jti": "4dabced9-459b-46ff-a622-8e0438e71686",
  "iss": "https://office.example.com/auth/realms/example.lan",
  "sub": "f:ldap_example.lan:test1",
  "typ": "Bearer",
  "azp": "cli_linshare",
  "sid": "6eb72191-a061-4064-abe9-9ec9d2b1dda9",
  "scope": "openid email linshare",
  "linshare_role": "SIMPLE",
  "email_verified": true,
  "external_uid": "test1",
  "last_name": "1 user",
  "first_name": "test",
  "domain_discriminator": "example.lan",
  "linshare_locale": "ENGLISH",
  "email": "[email protected]"
}

Along the way I had an issue with linshare_access: the claim had "linshare_access": "true", in the admin-ui Use access claim was enabled and linshare.properties contained: oidc.access.claim.value="true".
After the SSO login process returned from Keycloak, the UI failed on a http-status 500 from the linshare on tomcat. The logging on the server shows a null pointer exception:

15-Feb-2025 20:28:44.286 SEVERE [http-nio-127.0.0.1-8080-exec-3] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [CXFServlet] in context with path [/linshare] threw exception
        java.lang.NullPointerException: Cannot invoke "Object.toString()" because the return value of "org.springframework.security.core.Authentication.getPrincipal()" is null
                at org.linagora.linshare.auth.LinShareApplicationEventPublisher.publishAuthenticationFailure(LinShareApplicationEventPublisher.java:57)
                at org.springframework.security.authentication.ProviderManager.prepareException(ProviderManager.java:249)
                at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:189)
                at org.springframework.security.access.intercept.AbstractSecurityInterceptor.authenticateIfRequired(AbstractSecurityInterceptor.java:315)
                at org.springframework.security.access.intercept.AbstractSecurityInterceptor.beforeInvocation(AbstractSecurityInterceptor.java:203)
                at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:113)
                at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:81)
                at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:336)
                at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:122)
                at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:116)
                at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:336)
                at org.linagora.linshare.auth.jwt.JwtAuthenticationFilter.doFilterInternal(JwtAuthenticationFilter.java:79)
                at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
                at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:336)
                at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilterInternal(BasicAuthenticationFilter.java:166)
                at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
                at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:336)
                at org.linagora.linshare.auth.CORSRequestFilter.doFilterInternal(CORSRequestFilter.java:45)
                at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
                at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:336)
                at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:112)
                at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82)
                at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:336)
                at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:211)
                at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:183)
                at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:354)
                at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:267)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
                at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)
                at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
                at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:177)
                at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
                at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:769)
                at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360)
                at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399)
                at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
                at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:891)
                at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1784)
                at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
                at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
                at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
                at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
                at java.base/java.lang.Thread.run(Thread.java:840)

Should this be a bug report?

The easy way out was to disable Use access claim in the admin-ui, and with that I can login with SSO!

The current Keycloak oidc-client configuration for Linshare looks like this:

Important are:

Web origins: + to permit all origins of Valid Redirect URIs, this prevents the cors issue
Client authentication: Off to set a 'public access type' oidc client

Thank you for your help !

-- Kees.

0 replies

fabienmoyon · 2025-02-17T10:45:43Z

fabienmoyon
Feb 17, 2025
Maintainer

Hello @kvvloten,

Thanks and good news 👍

First of all you don't need to put the value of linshare_access between quotes, you can do "linshare_access": "true" to "linshare_access": true.

Second point, is it possible for you to contribute to our documentation by create the installation guide for integrating LinShare with KeyCloack. You can name it Integration with KeyCloack using OpenID Connect (OIDC) and put it in documentation/installation folder.
You can help you by following the lemonldap or microsoft-azure guides : https://github.com/linagora/linshare/blob/master/documentation/EN/installation/sso-lemonldap-using-OIDC.md and https://github.com/linagora/linshare/blob/master/documentation/EN/installation/sso-microsoft-azure-using-OIDC.md

Thanks a lot,
Regards,
Fabien

0 replies

kvvloten · 2025-02-20T17:09:50Z

kvvloten
Feb 20, 2025
Author

After changing the type to boolean the linshare_access parameter also works.

I will see what I can do to contribute some documentation for integration with Keycloak :-)

-- Kees.

1 reply

kvvloten Feb 21, 2025
Author

Documentation is available as a pull request: #345

-- Kees.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

How to configure Keycloak as OIDC provider for Linshare #333

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 17 comments 1 reply

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

How to configure Keycloak as OIDC provider for Linshare #333

kvvloten Oct 30, 2024

Replies: 17 comments · 1 reply

wboudiche Nov 4, 2024 Maintainer

kvvloten Nov 4, 2024 Author

wboudiche Nov 11, 2024 Maintainer

kvvloten Nov 11, 2024 Author

wboudiche Nov 14, 2024 Maintainer

wboudiche Nov 21, 2024 Maintainer

kvvloten Nov 21, 2024 Author

wboudiche Dec 5, 2024 Maintainer

kvvloten Dec 10, 2024 Author

wboudiche Jan 21, 2025 Maintainer

wboudiche Feb 10, 2025 Maintainer

kvvloten Feb 12, 2025 Author

wboudiche Feb 13, 2025 Maintainer

kvvloten Feb 13, 2025 Author

kvvloten Feb 15, 2025 Author

fabienmoyon Feb 17, 2025 Maintainer

kvvloten Feb 20, 2025 Author

kvvloten Feb 21, 2025 Author

kvvloten
Oct 30, 2024

Replies: 17 comments 1 reply

wboudiche
Nov 4, 2024
Maintainer

kvvloten
Nov 4, 2024
Author

wboudiche
Nov 11, 2024
Maintainer

kvvloten
Nov 11, 2024
Author

wboudiche
Nov 14, 2024
Maintainer

wboudiche
Nov 21, 2024
Maintainer

kvvloten
Nov 21, 2024
Author

wboudiche
Dec 5, 2024
Maintainer

kvvloten
Dec 10, 2024
Author

wboudiche
Jan 21, 2025
Maintainer

wboudiche
Feb 10, 2025
Maintainer

kvvloten
Feb 12, 2025
Author

wboudiche
Feb 13, 2025
Maintainer

kvvloten
Feb 13, 2025
Author

kvvloten
Feb 15, 2025
Author

fabienmoyon
Feb 17, 2025
Maintainer

kvvloten
Feb 20, 2025
Author

kvvloten Feb 21, 2025
Author