Supporting each other

Community forums

Welcome, Guest
Username: Password: Remember me
Questions on getting Xerte Toolkits installed on your server and questions about authentication and user logins.
  • Page:
  • 1

TOPIC:

sso integration - issue with login using PIN 1 month 5 days ago #9515

  • a.gibson@ulster.ac.uk
  • a.gibson@ulster.ac.uk's Avatar Topic Author
  • Offline
  • New Member
  • New Member
  • Posts: 4
  • Thank you received: 0
Hi, just wondering if anyone else has SSO integration with xerte. Have you experienced an issue with users who do not login to institution (Microsoft login) using the authenticator app and does this cause problems? We have SSO enabled and most users can login without a problem but 1 user is unable to login since we changed over to SSO an dI noticed that they are using a PIN to login to our university portal rather than the authenticator app. Any possible solutions would be much appreciated. Thanks, Aideen,

Please Inloggen or Create an account to join the conversation.

sso integration - issue with login using PIN 1 week 3 days ago #9542

  • rane46
  • rane46's Avatar
  • Offline
  • New Member
  • New Member
  • Posts: 1
  • Thank you received: 0
Hi,
We're encountering an issue with SSO integration where users are unable to log in using their PIN. The authentication process works fine for username and password, but when attempting to log in with a PIN, it either fails to authenticate or redirects improperly. We've verified the PINs are correctly stored and formatted. This may be related to the SSO provider not recognizing the PIN field as a valid credential input. Further debugging and possible coordination with the identity provider may be required to resolve this.

Please Inloggen or Create an account to join the conversation.

sso integration - issue with login using PIN 1 week 3 days ago #9543

  • tom
  • tom's Avatar
  • Away
  • Administrator
  • Administrator
  • Posts: 1329
  • Thank you received: 331
When using SSO with Xerte, the whole identification process is handled by the SSO solution. Only after the user is authenticated, the flow gets redirected to Xerte (or any other Service Provider (SP) for that matter). Xete does not receive the password and/or PIN and doesn't normally need to verify anything.

It just receives and uses the requested user attributes (username, first name and last name in Xerte's case.
The following user(s) said Thank You: a.gibson@ulster.ac.uk

Please Inloggen or Create an account to join the conversation.

sso integration - issue with login using PIN 1 week 15 hours ago #9549

  • a.gibson@ulster.ac.uk
  • a.gibson@ulster.ac.uk's Avatar Topic Author
  • Offline
  • New Member
  • New Member
  • Posts: 4
  • Thank you received: 0
The error we’re seeing is happening to several users, and the alert message we are receiving is in xerteauthissue.png attached.
We’ve asked the University MS Team, and they’ve said this is an application-side error.

Do you have instructions on how to remove the value RequestedAuthContext from the application – including files and folders to change, and their locations, and any pitfalls or unintended consequences we need to avoid? If this isn’t possible, could we have guidance on how to implement the second option below, to force a Fresh Authentication?
We have found Microsoft’s own guide on this error, online: Error - AADSTS75011 Authentication method by which the user authenticated with the service doesn't match requested authentication method AuthnContextClassRef. | Microsoft Learn

From this guide, the Cause is listed as:

“The RequestedAuthnContext is in the SAML request. This means the app is expecting the AuthnContext specified by the AuthnContextClassRef. However, the user has already authenticated prior to access the application and the AuthnContext (authentication method) used for that previous authentication is different from the one being requested. For example, a federated user access to MyApps and WIA occurred. The AuthnContextClassRef will be urn:federation:authentication:windows. Microsoft Entra ID won't perform a fresh authentication request, it will use the authentication context that was passed-through it by the IdP (ADFS or any other federation service in this case). Therefore, there will be a mismatch if the app requests other than urn:federation:authentication:windows. Another scenario is when MultiFactor was used: 'X509, MultiFactor.”

We are getting the Multifactor alert they reference in the last line above (shown in Pic 1 below). The Microsoft page also gives the solution, and it is to remove RequestedAuthnContext from the application, as authentication has already been ‘handled by the SSO solution’ as noted by the Xerte developers *in your email below, Aideen*. The problem is, we’re not sure what code we need to remove, or where to remove it from, to complete this resolution. This is what we need to answer.

Here’s Microsoft’s resolution in full:

“RequestedAuthnContext is an optional value. If possible, ask the application if the value could be removed.

Another option is to make sure that the RequestedAuthnContext value will be honored. This is done by requesting a fresh authentication. By doing this, when the SAML request is processed, a fresh authentication is done and AuthnContext is honored. In order to request a Fresh Authentication, the SAML request must contain the value, forceAuthn="true".”

xerteauthissue: Error alert attached
Attachments:

Please Inloggen or Create an account to join the conversation.

  • Page:
  • 1
Time to create page: 0.048 seconds
Copyright © 2025 The Xerte Project.
Xerte logo Apereo logo OSI Logo

Search