OIDC plugin Implementation

[deepak chauhan]

Hi 

I configured OIDC Plugin for SSO with Microsoft. I went through all the configurations and added memcache also. my login is working i see login redirected then i sign in with password. after password it shows connecting but then it redirects to homepage and shows no logged user as if user was not able to login. Any help would be appreciated

Configuration : 

1. Created activate-oidc-plugin
2. apps/qubit/config/settings.yml
   1. Change : login_module: oidc
3. config/factories.yml
   1. Change : user: class: oidcUser
4. /plugins/arOidcPlugin/config/app.yml

providers:

  primary:

    url: 'https://login.microsoftonline.com/<tenant-id>/v2.0'

    client_id: '<your-client-id>'

    client_secret: '<your-client-secret>'

    send_oidc_logout: false

    enable_refresh_token_use: true

    server_cert: false

    set_groups_from_attributes: false

    scopes:

      - 'openid'

      - 'profile'

      - 'email'

    user_matching_source: 'oidc-email' #i tried oidc-username also

    auto_create_atom_user: true

 

set_groups_from_attributes: false

 

redirect_url: 'site/index.php/oidc/login'

logout_redirect_url: 'site'

 

5. /config/factories.yml

prod:

  storage:

    class: QubitCacheSessionStorage

    param:

      session_name: symfony

      session_cookie_httponly: true

      session_cookie_secure: true

      cache:

        class: sfMemcacheCache

        param:

          host: memcached 

          port: 11211

          prefix: atom

          storeCacheInfo: true

          persistent: true

6. Php symfony cc
7. Restart php-fpm

[Alberto Pereira]

Hi Deepak,

check the thread below, I think it's the same issue:
https://groups.google.com/g/ica-atom-users/c/jcEP9HKODvs/m/ZM73abDPBgAJ

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/44c5e435-ba67-46bb-98bc-924144028415n%40googlegroups.com.

[deepak chauhan]

hi Alberto i saw your advice of commenting out the session destroy in 

1. /lib/QubitSessionStorage.class.php, line 54

but we are using QubitCacheSessionStorage in place of it,  configuration for Memcache as backend 

Anyway i tried commenting out session destroy, unfortunately it didn't help. Do you have any other step to try?

Thanks

[pieters...@gmail.com]

Hi Alberto

 

Since it redirects to the homepage (not to `admin/secure`), your `authenticate()` is almost certainly succeeding and `signIn()` is running - the login is being lost on the *next* request, which points at the session not persisting rather than at the OIDC config. The OIDC state/nonce also live in the session, so everything hinges on memcache round-tripping correctly. A few things to try, in order:

 

1. Isolate memcache first (best single test)

 

Temporarily switch your session storage in `config/factories.yml` from `QubitCacheSessionStorage` back to the default file-based `QubitSessionStorage`, clear the cache (`php symfony cc`), restart php-fpm, and retry the OIDC login. If the login now sticks, the OIDC plugin is fine and the problem is your memcache session layer.

 

yaml

prod:

  storage:

    class: QubitSessionStorage

    param:

      session_name: symfony

      session_cookie_httponly: true

      session_cookie_secure: true

 

2. Check the memcache extension and connectivity

 

‘sfMemcacheCache’ uses the *legacy* `Memcache` class, not `Memcached`. Confirm on the php-fpm host:

 

php -r 'var_dump(class_exists("Memcache"));'   # must be true

 

Critically, `Memcache::addServer()` returns success even when the host is unreachable, so writes can fail silently. Verify php-fpm can actually reach the `memcached` host and that items are being stored across a login attempt:

 

printf "stats\r\n" | nc memcached 11211        # watch curr_items / cmd_set climb

 

If php-fpm cannot resolve or reach `memcached`, sessions never persist even though the rest of the site appears to work.

 

3. Watch the log during the callback

 

`oidcUser` logs `OIDC exception: ...` on a state/nonce mismatch. Tail your qubit/php-fpm log while logging in:

 

- If you see that exception, the session is being lost “before” the callback (cookie or memcache round-trip).

- If you see no exception and a sign-in, it is lost “after” sign-in (session regeneration not written to memcache) - which matches your homepage symptom.

 

4. Proxy / HTTPS

 

`QubitCacheSessionStorage` drops the secure cookie flag when it thinks the request is not HTTPS. If you terminate TLS at a reverse proxy, make sure AtoM sees HTTPS (trust `X-Forwarded-Proto`) so the session cookie and the generated redirect_uri stay consistent.

 

5. Confirm the `email` claim is present

 

With `user_matching_source: oidc-email`, Entra ID often does not emit an `email` claim unless the user has a mail attribute or you add it as an optional claim in the app registration. Worth verifying, though given you reach the homepage the match is probably working.

 

 

My money is on #1 / #2 - a silent memcache write failure. Start there.

 

Groete / Regards

Johan Pieterse

082 337-1406

https://heratio.theahg.co.za

To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/bcabcc4a-42d0-4977-8e45-6da32dd44f45n%40googlegroups.com.

[Alberto Pereira]

Hi Deepak,

Apologies, only now I've read in more detail the configuration details you showed.
Why did you add

cache:
        class: sfMemcacheCache
        param:
          host: memcached
          port: 11211
          prefix: atom
          storeCacheInfo: true
          persistent: true

To the storage config in factories.yml? The cache is defined for data, in app.yml, which is fine, but this is for session storage, which I suppose would work, but does not make a difference and can have unpredictable results.

Can you remove it and try again?

Also, what version of AtoM are you using?

And don't forget to clear the cache and restart php-fpm (if in use and just in case), after the changes.

To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/bcabcc4a-42d0-4977-8e45-6da32dd44f45n%40googlegroups.com.

[deepak chauhan]

thanks Alberto AND Johan,

Alberto - i was following Atom documentation. I have switched it back to Qubitsessionstorage and still it doesn't help.

Johan- thanks for extensive detailed steps: I went through all of them and they didn't help me. MS logs tell that session was successful meaning plugin is at fault. I don't know if this helps : 

once i am redirected to homepage without user logged in:

1. Status Code 302 Found

2. set-cookie atom_authenticated=deleted; expires=Thu, 01 Jan 1970 00:00:01 GMT; Max-Age=0; path=/; secure; SameSite=strict

Looks like plugin is not handling the session well. ATOM - Version 2.9 

[Alberto Pereira]

Hi Deepak,

These:

1. Status Code 302 Found

2. set-cookie atom_authenticated=deleted; expires=Thu, 01 Jan 1970 00:00:01 GMT; Max-Age=0; path=/; secure; SameSite=strict

Are both from the same request? Something like "GET /oidc/login[...]"? Because the 302 is the redirect, there should be one just after, like "GET /", with different headers and a 200 Code.

Also, there should also be other headers. Can you look for the one with "Set-Cookie: symfony=[...]"? Does it exist?

You can also print a few debug lines to see if session_destroy is still being called.

Right at the top of the function regenerate in /lib/QubitSessionStorage.class.php, something like

error_log(sprintf('$_SESSION keys BEFORE: %s', implode(',', array_keys($_SESSION ?? []))));

and at the very end

error_log(sprintf('$_SESSION keys AFTER: %s', implode(',', array_keys($_SESSION ?? []))));    

then check the server error logs (or php-fpm, but usually /var/log/nginx/error_log). Both outputs should be the same.

And yes, for now I'd still advance assuming the session persistence is the issue. 

To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/87ada75e-6b24-43c5-a267-668d07bdbbd9n%40googlegroups.com.

[deepak chauhan]

Hi Alberto,

I can see the Set-Cookie header for the symfony cookie in the callback response:

/index.php/oidc/login?code=1.AXUAcZYxzedSaEqvqfz4-J8J6oAXxeUBHDNGj...

At this point, it looks more like a plugin issue than an issue with Entra ID.

I am using QubitCacheSessionStorage, since the AtoM documentation for OIDC states that an external cache is required. My AtoM version is 2.9. Could that be related to the issue?

I also tried commenting out session_destroy() again. After completing the login process, the site returned a 500 Internal Server Error instead of redirecting back to the home page, as if the session handling failed. I’ve attached a screenshot.

cache-control

no-store, no-cache, must-revalidate

connection

keep-alive

content-type

text/html; charset=utf-8

date

Tue, 14 Jul 2026 19:19:09 GMT

expires

Thu, 19 Nov 1981 08:52:00 GMT

location

https://datm-archivalcollections.library.mcgill.ca/

pragma

no-cache

set-cookie

atom_culture=en; path=/; secure; HttpOnly; SameSite=strict

set-cookie

atom_authenticated=deleted; expires=Thu, 01 Jan 1970 00:00:01 GMT; Max-Age=0; path=/; secure; SameSite=strict

set-cookie

PHPSESSID=d6d279d889780ab2636aab24b3d55505; path=/; SameSite=Lax; Secure;

set-cookie

symfony=c9edb504727e6a7160c06795334ded4c:a9cfe8a431fb29ab044b932e1ce2e7e3abd42e5d; expires=Thu, 13 Aug 2026 19:19:09 GMT; Max-Age=2592000; path=/; secure; HttpOnly; SameSite=Lax;

set-cookie

TS0191d563=01780f7ad0768c4c8862516668e8e2514712775913ae0c3ba711d44f3db95816cfd6fea73b561c88ca3215f85ccb1661b89923fdef; Path=/; Domain=.datm-archivalcollections.library.mcgill.ca; HttpOnly

strict-transport-security

max-age=63072000; includeSubDomains; preload

transfer-encoding

chunked

[deepak chauhan]

hi Alberto,

is there anything we could do ?

[Alberto Pereira]

Hi,

Whenever you see a 500 error on the browser, the web server error log should have more information. After running it again to trigger the error, check what the log says. Should be in /var/log/nginx/error.log.

To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/ca5e4b5e-d310-487c-908e-e7da761fa8b7n%40googlegroups.com.