Forum Discussion
jinzhong he
Nov 07, 2021Copper Contributor
Third party oidc authentication with SPSE failed
Following the new oidc-1-0-authentication , I managed configuring oidc authenticate in SPSE with ADFS. I then tried third party oidc authentication in SPSE with Keycloak, but failed with following ...
Steve Zhang
Microsoft
Jan 04, 2022cangot We identified the problem with Jinzhong, we will have a fix soon.
I don't have a steps for configuration in hand, but you can follow the doc we published (OpenID Connect 1.0 authentication - SharePoint Server | Microsoft Docs). It will be similar for 3rd party OIDC IDP. I think Jinzhong was following that as well.
bdecamp
Jan 07, 2022Copper Contributor
We're having this issue in Keycloak and Red Hat SSO (RH-SSO) as well when attempting to implement OIDC in Sharepoint Subscription Edition.
We've found the cause of the issue. It is caused by an incomplete OIDC client implementation in Sharepoint subscription edition. Sharepoint is failing to perform proper OIDC Token validation steps for the ID and Access tokens it receives. And instead depends on a manual one-time import of the signing certificate, with the administrator manually browsing to the JWKS URL to acquire the Identity providers signing certificate. This is supposed to be done dynamically by the OIDC client.
Notice this manual step in the official documentation that is required when initially configuring Sharepoint OIDC https://docs.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/oidc-1-0-authentication :
"Open jwks_uri (https://login.microsoftonline.com/common/discovery/keys), and save the x5c certificate string of the first key for later use in SharePoint setup (if the first key doesn’t work, try the second or third key)."
Then later in the documentation, the manually acquired cert is used to add a new SP Trusted Identity Token Issuer:
# Public key of the AAD OIDC signing certificate. Please replace <x5c cert string> with the encoded cert string which you get from x5c certificate string of the keys of jwks_uri from Step #1
$encodedCertStr = <x5c cert string>
$signingCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 @(,[System.Convert]::FromBase64String($encodedCertStr))
# Create a new SPTrustedIdentityTokenIssuer in SharePoint
New-SPTrustedIdentityTokenIssuer -Name "contoso.local" -Description "contoso.local" -ImportTrustCertificate $signingCert -ClaimsMappings $email -IdentifierClaim $email.InputClaimType -RegisteredIssuerName $registeredissuernameurl -AuthorizationEndPointUri $authendpointurl -SignOutUrl $signouturl -DefaultClientIdentifier $clientIdentifier
Notice the ambiguity of the documentation quote that further highlights the root problem: "if the first key doesn’t work, try the second or third key". This ambiguity makes clear the fact that Sharepoint is not able to dynamically lookup the certificate to use from the JWKS URL the way OIDC specifies. The administrator performs the lookup manually during configuration. This precludes ever changing the Identity Provider signing keys, as changing the signing key would require another manual import of the new signing certificate. Changing signing keys is designed to be transparent and possible without breaking client applications per the OIDC spec.
The OIDC spec says the dynamic lookup of the certificate is done by the OIDC Client using the 'kid' value in the ID or Access Token it receives, it is supposed to compare the kid value to the list of certificates provided by the identity provider at the JWKS URL to dynamically discover the x5c certificate to use for the validation. This step is entirely skipped by Sharepoint Subscription Edition.
The only reason OIDC works at all in Sharepoint Subscription Edition, and only when using ADFS or Azure AD, is from these coincidental behaviors:
1. The signing cert is manually imported in advance by the administrator by interactively visiting the JWKS URL of the Identity Provider, and manually providing that certificate to New-SPTrustedIdentityTokenIssuer powershell command. But even this manual step results in ambiguous results per the documentation: "if the first key doesn’t work, try the second or third key". As there may be multiple signing certificates in use by the IdP.
2. ADFS and Azure AD always use the x5t thumbprint of the signing certificate as the kid value (key id). This allows sharepoint to simply match the kid value from the ID or Access Token to the thumbprint of the certificate in sharepoint's local Certificate Trust storage, bypassing the proper OIDC spec which states sharepoint should lookup the certificate via the JWKS URL, and match the results using the kid value in the access/id token.
Even with the non OIDC compliant manual certificate import step, Keycloak still doesn't work with Sharepoint. This is further highlighting sharepoint's OIDC logic deficiency: Keycloak uses a unique GUID for the kid, instead of the x5t value (this is compliant behavior, the x5t value simply needs to be unique. ADFS and Azure AD always use x5t as the kid value, which is also compliant behavior as the x5t value is a sha1 hash, which is generally unique). So even if you perform the manual JWKS certificate import when setting up Keycloak as sharepoint OIDC Identity Provider, Sharepoint is unable to match the 'kid' value from Keycloak to its local certificate store, as sharepoint only stores the sha1 thumbprint, not the kid value from the Identity Provider. Sharepoint is making the incorrect assumption that the kid value is always the sha1 thumbprint of the signing certificate, this assumption is only valid for IdP's that use the sha1 thumbprint as the kid value, as is the case with ADFS and Azure AD.
In conclusion, point 1 is the real issue that needs fixed. Sharepoint needs to follow the OIDC specification and dynamically query the JWKS URL to discover the certificates used by the Identity Provider, and then match the 'kid' value from the ID / Access Token to get the proper certificate to use for validation dynamically.
Alternatively the issue can be mostly worked-around by changing Keycloak to always use the sha1 thumbprint of the certificate as the "kid" value of OIDC tokens (would have to be done in code, it is not configurable to change the kid format in Keycloak runtime settings). But this still would require the non standard manual import of the signing certificate into sharepoint. So this work around still leaves the root problem unsolved, which is sharepoint does not dynamically lookup the JWKS URL, and instead depends on one-time administrator manual lookup and import of the signing cert from the JWKS url of the Identity Provider. This work-around also precludes the ability to ever change the signing certificate without manually re-importing the certificate and re-configuring Sharepoint from powershell. This work-around simply makes Keycloak behave like ADFS and Azure AD. If point 1 is fixed, then the work-around is no longer needed for Keycloak, as sharepoint will no longer make the assumption that the kid value always matches the cert thumbprint. It will be able to lookup the validation certificate no matter what kid format is used by an IdP.
- jsipesApr 19, 2024Copper ContributorAny update on "We've put the kid work into backlog and we will work on it with priority." ?
- TroyStarrAug 29, 2022
Microsoft
Hi ictotum, you can open a support case by going to https://support.microsoft.com/contactus, then clicking Show expanded list of products, then clicking SharePoint Server. The cost to open a support case will depend on the type of support contract your organization has with Microsoft.
- ictotumAug 29, 2022Copper Contributorhow's that? Is it free? How can I open it? Thanks
- Steve ZhangAug 29, 2022
Microsoft
Would you mind opening a support ticket to us for your specific problem? We will be able to follow up with you.
And also add TroyStarr here as well.
- ictotumAug 04, 2022Copper ContributorIt seems you can help me for an issue with another third party... Forgerock. Do I have to open a new discussion? I try to list here... SE configured with 3 data: 1) claim to map (EmailAddress), 2) metadata URL (has everything there), 3) client ID. I don't know if the auth provider team should do something else, they told me the claim they treat is "email", not "EmailAddress", maybe that's the issue? The authentication error, in SharePoint, is... the claim is void or not recognized. LOGS > "No identity provider claim on the identity..." "Initialized session revocation members. Auth instant: 'null'. IAT: 'null'. ValidFrom: 'null'. Operation type: '' ..." "Initialize session attributes: Did not find any. Current value: 'None'..." "Trusted login provider is not sending configured input identity claim type..." "Throwing fault exception because there is no identity claim..." "An exception occurred when trying to issue security token: The trusted login provider did not supply a token accepted by this farm"
- benjamin8733Mar 22, 2022Copper Contributor
Thanks so much jinzhong he! Knowing you got it working helped me get to the bottom of our issue.
On our keycloak instances (latest 17.0.0 quarkus version), in a new test realm, the default for "Access Token Lifespan" is set to 5 minutes. (For reference, on ADFS, this same value defaults to 60 minutes).
This is all fine usually, as many apps, (excluding sharepoint), we've tested on both keycloak and adfs work fine with either IdP with default timeouts.
But sharepoint has an odd behavior, in that by default: "when there are less than 10 minutes left in the lifetime SharePoint considers it expired" (quote from https://sharepoint.stackexchange.com/users/3338/infotekka at SharePoint 2013 ADFS login local token cache always expired - SharePoint Stack Exchange )
The ULS logs confirmed the issue after sso login: "Found matching token cache entry but it's token is expired."
So sharepoint was rejecting the token as expired immediately after the successful SSO login from keycloak had completed. Adjusting the keycloak realm settings for "Access Token Lifespan" to 60 minutes up from the default 5 minutes fixed our issue. Login to sharepoint is now working correctly against keycloak.
- jinzhong heMar 21, 2022Copper ContributorThe client scopes were the default(emial, profile, etc), The IdentifierClaim I used on the sharepoint side was the UPN, and on the keycloak side, I mapped username to upn.
- benjamin8733Mar 18, 2022Copper Contributor
Could you list what client scopes and mappers you've configured in keycloak to get this to work? and what claim type you've configured on the sharepoint side to recieve those claims?
So far i've been unsuccessful in getting keycloak to work with SPSE, although now the token is validating correctly (per the ULS logs) since the March CU, so appears i'm missing some critical claims for sharepoint to grant access.
Currently I'm attempting to use "email" as the claim on both sides to match.
- jinzhong heMar 18, 2022Copper Contributor
benjamin8733 see the attached screenshot.
You need to create token mappers for username mapping.
- benjamin8733Mar 17, 2022Copper Contributor
Would you mind posting a screenshot or an export of your sharepoint client config inside of keycloak now that you've got it working? Or even just an example access or id token that has the claims you added to get it working?
Thanks for anything you can provide to help us out!
- jinzhong heMar 16, 2022Copper ContributorThe March PU worked. Thanks.
- Steve ZhangMar 16, 2022
Microsoft
It's good to know the fix really works. For the page js errors, yes, we can start another new discussion with new post. - Hasan KöroğluMar 15, 2022Brass ContributorHi again Steve,
As you suggest, after march update, keycloak and SP-SE integration worked. But this time portal pages (modern experience sites) throw js errors. i think i have to start a new discussion. Thanks again. - Hasan KöroğluMar 15, 2022Brass ContributorHi Steve,
Thanks for the quick reply. i will update the farm asap. i'll get informed you after the upgrade. - Steve ZhangMar 15, 2022
Microsoft
Thanks Hasan,
By looking at the log, your SharePoint version(16.0.14326.20620) is not latest, our fix is in March PU.
Could you please have a try with March PU? You can get latest PU from: https://docs.microsoft.com/en-us/officeupdates/sharepoint-updates - Hasan KöroğluMar 15, 2022Brass Contributor
03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Logging Correlation Data xmnv Medium Name=Request (POST:https://oidctest.contoso.local/_layouts/15/Authenticate.aspx?Source=%252F) b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Asp Runtime avwhz Medium SPRequestModule.BeginRequestHandler End, SP Build Version: '16.0.14326.20602' b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Nonce Cookie 9brd4 Medium SPContextCookie : Using full host domain for cookie. CookieName: 'nSGt'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Nonce Cookie 9brdr Medium SPCryptoContextCookie : Initial Secondary certificate is null and we did not receive a secondary certificate thumbprint. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Nonce Cookie 9brc8 Medium SPNonceCookie : The Identifier is set successfully. Identifier: '', NonceToSendToIdentityProvider: '1052C7C0B64939E9AD4ED9E0AE79DA9377E650180CDEE9B5-7EADB364F29A63E9C52B0B4B33A094168CDC8354D8D684DF522F06FD78AD4188'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Claims Authentication 9w647 Medium Using input cookie name. CookieName: 'nSGt-1052C7C0B64939E9AD4ED9E0AE79DA9377E650180CDEE9B5'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Nonce Cookie 9brbv Medium SPNonceCookie : Successfully read nonce cookie. Version: '0', Seed: '9DA2E444C81E8DA541AC5FEC919C82198F7FD7BDD6403B93', Identifier: '1052C7C0B64939E9AD4ED9E0AE79DA9377E650180CDEE9B5'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Nonce Cookie 9brc8 Medium SPNonceCookie : The Identifier is set successfully. Identifier: '1052C7C0B64939E9AD4ED9E0AE79DA9377E650180CDEE9B5', NonceToSendToIdentityProvider: '1052C7C0B64939E9AD4ED9E0AE79DA9377E650180CDEE9B5-7EADB364F29A63E9C52B0B4B33A094168CDC8354D8D684DF522F06FD78AD4188'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Claims Authentication 9w647 Medium Using input cookie name. CookieName: 'nSGt-1052C7C0B64939E9AD4ED9E0AE79DA9377E650180CDEE9B5'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Authentication Authorization deffe Medium The browser does support SameSite at revision 3 of RFC6265. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Nonce Cookie 9brbj Medium SPNonceCookie : Deleted nonce cookie if present. Identifier: '1052C7C0B64939E9AD4ED9E0AE79DA9377E650180CDEE9B5'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Security Token Handler 8p0r7 Medium Audience GUID matches trusted login provider default client identifier. Audience: 'oidctest', provider Default Identifier: 'oidctest', provider Uri: ''. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.33 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Topology aeayb Medium SecurityTokenServiceSendRequest: RemoteAddress: 'http://localhost:32843/SecurityTokenServiceApplication/securitytoken.svc' Channel: 'System.ServiceModel.Security.IWSTrustChannelContract' Action: 'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue' MessageId: 'urn:uuid:b7edff6c-0098-4e63-adcb-f52ab2636b2a' b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0x8518) 0xF464 SharePoint Foundation Topology aeax9 Medium SecurityTokenServiceReceiveRequest: LocalAddress: 'http://sp04.sp.local:32843/SecurityTokenServiceApplication/securitytoken.svc' Channel: 'System.ServiceModel.Channels.ServiceChannel' Action: 'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue' MessageId: 'urn:uuid:b7edff6c-0098-4e63-adcb-f52ab2636b2a' b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0x8518) 0xF464 SharePoint Foundation Monitoring nasq Medium Entering Monitored Scope (ExecuteSecurityTokenServiceOperationServer). Parent=None b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0x8518) 0xF464 SharePoint Foundation Security Token Service 9w6kv Medium STS Call: Creating Claims Operations Scope for Applies To Uri: 'https://oidctest.contoso.local/'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0x8518) 0xF464 SharePoint Foundation Claims Authentication a6oo7 Medium Created claims operation context from uri. ContextUri: 'https://oidctest.contoso.local/', Source: 'SiteWithoutSiteSubscription'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0x8518) 0xF464 SharePoint Foundation Security Token Service 9w6k3 Medium Creating SPSecurityTokenRequestContextV2 object for security token service Issue request. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0x8518) 0xF464 SharePoint Foundation Security Token Service 9w6k0 Monitorable STS Call: Failed to issue new security token. Exception: 'System.IdentityModel.Tokens.SecurityTokenException: Validate signature failure : no found matched security key for token signature. at Microsoft.SharePoint.IdentityModel.SPOpenIDSecurityTokenHandlerV2.ValidateSignature(String token, TokenValidationParameters validationParameters) at System.IdentityModel.Tokens.JwtSecurityTokenHandler.ValidateToken(String securityToken, TokenValidationParameters validationParameters, SecurityToken& validatedToken) at Microsoft.SharePoint.IdentityModel.SPOpenIDSecurityTokenHandlerV2.ValidateToken(String tokenString, TokenValidationParameters validationParameters, SecurityToken& token) at Microsoft.SharePoint.IdentityModel.SPOpenIDSecurityTokenHandlerV2.ValidateToken(SecurityToken token) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenRequestContextV2..ctor(ClaimsIdentity identity, RequestSecurityToken request, Boolean initializeForActor, SPSecurityTokenRequestTypeV2 overrideRequestType) at Microsoft.SharePoint.IdentityModel.SPSecurityTokenServiceV2.Issue(ClaimsPrincipal principal, RequestSecurityToken request)'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0x8518) 0xF464 SharePoint Foundation Monitoring b4ly Medium Leaving Monitored Scope: (ExecuteSecurityTokenServiceOperationServer) Execution Time=3.2962; CPU Milliseconds=3; SQL Query Count=0; Parent=None b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Security Token Service Caller btgia High SPSecurityContext: Request for security token failed with exception. Exception: 'System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs. at System.ServiceModel.Security.WSTrustChannel.ReadResponse(Message response) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs, SecurityToken delegateTo, SPRequestSecurityTokenProperties properties)'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Claims Authentication 8306 Critical An exception occurred when trying to issue security token: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.34 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Claims Authentication 9w636 Unexpected Claims Saml Sign-In: Could not get local token for trusted third party token. FaultException: 'System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs. at System.ServiceModel.Security.WSTrustChannel.ReadResponse(Message response) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs, SecurityToken delegateTo, SPRequestSecurityTokenProperties properties) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForOnBehalfOfContext(Uri context, SecurityToken onBehalfOf) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.ExchangeArgumentTrustedThirdPartySessionSecurityTokenForLocalToken(SecurityToken thirdPartyToken, SessionSecurityTokenCreatedEventArgs arguments)'. Stack: ' at System.ServiceModel.Security.WSTrustChannel.ReadResponse(Message response) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs, SecurityToken delegateTo, SPRequestSecurityTokenProperties properties) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForOnBehalfOfContext(Uri context, SecurityToken onBehalfOf) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.ExchangeArgumentTrustedThirdPartySessionSecurityTokenForLocalToken(SecurityToken thirdPartyToken, SessionSecurityTokenCreatedEventArgs arguments)'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Asp Runtime avwhw Medium SPRequestModule.ErrorAppHandler Begin b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation General 8nca Medium Application error when access /_layouts/15/Authenticate.aspx, Error=The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs. at System.ServiceModel.Security.WSTrustChannel.ReadResponse(Message response) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs, SecurityToken delegateTo, SPRequestSecurityTokenProperties properties) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForOnBehalfOfContext(Uri context, SecurityToken onBehalfOf) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.ExchangeArgumentTrustedThirdPartySessionSecurityTokenForLocalToken(SecurityToken thirdPartyToken, SessionSecurityTokenCreatedEventArgs arguments) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.OnSessionSecurityTokenCreated(SessionSecurityTokenCreatedEventArgs eventArgs) at System.IdentityModel.Services.WSFederationAuthenticationModule.SetPrincipalAndWriteSessionToken(SessionSecurityToken sessionToken, Boolean isSession) at System.IdentityModel.Services.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequestBase request) at System.IdentityModel.Services.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.OnAuthenticateRequest(Object sender, EventArgs eventArgs) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Runtime tkau Unexpected System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs. at System.ServiceModel.Security.WSTrustChannel.ReadResponse(Message response) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs, SecurityToken delegateTo, SPRequestSecurityTokenProperties properties) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForOnBehalfOfContext(Uri context, SecurityToken onBehalfOf) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.ExchangeArgumentTrustedThirdPartySessionSecurityTokenForLocalToken(SecurityToken thirdPartyToken, SessionSecurityTokenCreatedEventArgs arguments) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.OnSessionSecurityTokenCreated(SessionSecurityTokenCreatedEventArgs eventArgs) at System.IdentityModel.Services.WSFederationAuthenticationModule.SetPrincipalAndWriteSessionToken(SessionSecurityToken sessionToken, Boolean isSession) at System.IdentityModel.Services.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequestBase request) at System.IdentityModel.Services.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.OnAuthenticateRequest(Object sender, EventArgs eventArgs) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation General ajlz0 High Getting Error Message for Exception System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs. at System.ServiceModel.Security.WSTrustChannel.ReadResponse(Message response) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr) at System.ServiceModel.Security.WSTrustChannel.Issue(RequestSecurityToken rst) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs, SecurityToken delegateTo, SPRequestSecurityTokenProperties properties) at Microsoft.SharePoint.SPSecurityContext.SecurityTokenForOnBehalfOfContext(Uri context, SecurityToken onBehalfOf) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.ExchangeArgumentTrustedThirdPartySessionSecurityTokenForLocalToken(SecurityToken thirdPartyToken, SessionSecurityTokenCreatedEventArgs arguments) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.OnSessionSecurityTokenCreated(SessionSecurityTokenCreatedEventArgs eventArgs) at System.IdentityModel.Services.WSFederationAuthenticationModule.SetPrincipalAndWriteSessionToken(SessionSecurityToken sessionToken, Boolean isSession) at System.IdentityModel.Services.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequestBase request) at System.IdentityModel.Services.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) at Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModuleV2.OnAuthenticateRequest(Object sender, EventArgs eventArgs) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation General aat87 Monitorable b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Authentication Authorization agb9s Medium Non-OAuth request. IsAuthenticated=False, UserIdentityName=, ClaimsCount=0 b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation General agxkz High calling GetCurrentGenericSetupPath for a versioned path: TEMPLATE\LAYOUTS b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Application Authentication 9s97c Medium SPApplicationAuthenticationModuleV2.IsBearerChallengeRequested: Return 'False'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Application Authentication 9s97n Medium The request isn't made to a page which allows NeverAuth to be specified in the query string b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Claims Authentication crpqx Medium STS setting for SuppressModernAuthForOfficeClients:'True'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Application Authentication 9s976 Medium IsClaimsTrustedAuthenticationOnly: 'False', IsOfficeClientIDCRLRequest: 'False', HasSPTrustedSecurityTokenIssuer: 'False', ForceIdcrlForOfficeClients: 'True'. b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Asp Runtime avwh5 Medium SPRequestModule.PreSendRequestHeaders End b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Asp Runtime avwhx Medium SPRequestModule.ErrorAppHandler End b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Asp Runtime avwia Medium SPRequestModule.PostLogRequestHandler Begin b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Asp Runtime avwib Medium SPRequestModule.PostLogRequestHandler End b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Asp Runtime avwic Medium SPRequestModule.EndRequestHandler Begin b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Micro Trace uls4 Medium Micro Trace Tags: 0 avwhy,0 nasq,1 avwhz,0 9brd4,0 9brdr,0 9brc8,0 9w647,0 9brbv,0 9brc8,0 9w647,0 deffe,0 9brbj,2 8p0r7,1 aeayb,12 btgia,0 9w636,0 avwhw,0 8nca,0 tkau,0 ajlz0,1 aat87,2 agb9s,0 agxkz,1 9s97c,0 9s97n,0 crpqx,0 9s976,0 avwh5,0 avwhx,0 avwia,0 avwib,0 avwic b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Runtime aoxsq Medium Sending HTTP response 200 for HTTP POST request b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Unified Audit bm7sm High SPRequestModule::CreatePageViewedAuditEntry: Required parameters not set properly,exiting creating PageViewed SPUnifiedAuditEntry b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Monitoring b4ly Medium Leaving Monitored Scope: (Request (POST:https://oidctest.contoso.local/_layouts/15/Authenticate.aspx?Source=%252F)) Execution Time=26.8099; CPU Milliseconds=16; SQL Query Count=0; Parent=None b2ec29a0-34e1-808c-08b8-fecdfcecba7e 03.15.2022 11:07:41.35 w3wp.exe (0xF50C) 0x11814 SharePoint Foundation Asp Runtime avwid Medium SPRequestModule.EndRequestHandler End b2ec29a0-34e1-808c-08b8-fecdfcecba7e
- Steve ZhangMar 09, 2022
Microsoft
Hasan Köroğlu could you please share the ULS log?
- Hasan KöroğluMar 09, 2022Brass Contributor
Hi Steve,
The March CU has been released, but i couldn't see any solution for our problem. Can you share the roadmap for this issue with us?
Thanks.
- Steve ZhangFeb 09, 2022
Microsoft
Removing spaces should be done by IDP
For example,
{"alg":"RS256","typ":"JWT","kid":"xxx"}. This claim works
{"alg":"RS256","typ" : "JWT","kid" : "xxx"}. This will cause Validate signature failure because there are extra space before and after ":".
- jinzhong heFeb 08, 2022Copper ContributorI just checked the claims and removed the claims that contain spaces, but got the same wrong result.
- Steve ZhangFeb 08, 2022
Microsoft
Hasan Köroğlu and bdecamp ,
We are working on the fix of Kid. Due to the requirement of security strengthening, we can't immediately update certificate cache when kid doesn't match because user auth flow are running in normal user credential.
Instead, we can run a timer job in the background to regularly refresh certificate from metadata endpoint. Admin can set when timer job gets run and in which frequency. Does it work for your scenario?
Thanks
Steve
- Hasan KöroğluFeb 01, 2022Brass Contributor
- Steve ZhangJan 12, 2022
Microsoft
Thank you very much bdecamp. We've put the kid work into backlog and we will work on it with priority.
For Jinzhong's problem, the issue happens when the claims include special characters such as CR, LF, space and etc. The characters are wrongly treated. I just checked the release schedule, it may not catch up Feb PU. It will be in March PU. To workaround this problem, you can check if you can remove these kind of characters from the claim in the response. After the workaround, it should work although we don't respect kid currently. - bdecampJan 10, 2022Copper Contributor
"In the validate flow, we are not using kid." this doesn't make sense; the kid is required to be used to be able to lookup the proper x5c cert to use for validation, either from a cached copy of the JWKS url contents, or from the JWKS url directly. The kid in the token header is what's used to lookup the correct x5c certificate to use to validate. Sounds like sharepoint is taking a shortcut and not correctly looking up the x5c cert to use, as I discussed in my post.
Either way, looking forward to an eventual fix for this critical issue. We have many OIDC applications deployed against ADFS and Keycloak. Only Sharepoint has an issue when configured with Keycloak.
Please let us know what the issue is for Jinzhong, as we could use a workaround in the meantime.For reference, below is the overview of how an OIDC client application is supposed to validate an incoming OIDC ID or Access token. There is simply no way to follow the OIDC standard, and have this statement be true: "In the validate flow, we are not using kid."
Take note of steps 3, get the kid value, step 4, match it to the data from the JWKS (directly or cached), and 5, get the x5c certificate for that specific kid (key id).
(from: https://auth0.com/blog/navigating-rs256-and-jwks/)
Here are the steps for validating the JWT:
- Retrieve the JWKS and filter for potential signature verification keys.
- Extract the JWT from the request's authorization header.
- Decode the JWT and grab the kid property from the header.
- Find the signature verification key in the filtered JWKS with a matching kid property.
- Using the x5c property build a certificate which will be used to verify the JWT signature.
- Ensure the JWT contains the expected audience, issuer, expiration, etc.
- Steve ZhangJan 10, 2022
Microsoft
Hi bdecamp
Thank you very much for the details about what you observed. From the manual configuration step, certificate need to be provided. In that flow, we currently support one certificate in that parameter set. We have the work in the backlog to improve the manual setup already.
And for the problem of x5t kid vs GUID kid, as SharePoint can't afford to validate token by calling JWKS url frequently, we store the certificate locally from what metadata endpoint provided. In the validate flow, we are not using kid. We are using the stored certificate to validate the token. So it doesn't matter what is the format of kid. But the requirement is certificate must be in x5c format currently. Could you please check if it works?
BTW, Jinzhong's problem is a different one. We have the fix and will be published soon, hopefully in February.