I use OpenID authentication and all of the providers have been tested and work fine when running the website from Visual Studio. I have deployed the website to the server and the Google and myOpenID work just fine but Yahoo! OpenID provider just throws this error...
The OpenID Provider issued an
assertion for an Identifier whose
discovery information did not match.
Assertion endpoint info:
ClaimedIdentifier:
https://me.yahoo.com/a/KyzgPcp9v8xRcWxFNKx357hQTxZ9P7Udww8bPkpv3oNSoogH0IXw#11950
ProviderLocalIdentifier:
https://me.yahoo.com/a/KyzgPcp9v8xRcWxFNKx357hQTxZ9P7Udww8bPkpv3oNSoogH0IXw
ProviderEndpoint:
https://open.login.yahooapis.com/openid/op/auth
OpenID version: 2.0 Service Type URIs:
Discovered endpoint info: [{
ClaimedIdentifier:
http://specs.openid.net/auth/2.0/identifier_select
ProviderLocalIdentifier:
http://specs.openid.net/auth/2.0/identifier_select
ProviderEndpoint:
https://open.login.yahooapis.com/openid/op/auth
OpenID version: 2.0 Service Type URIs:
http://specs.openid.net/auth/2.0/server
http://specs.openid.net/extensions/pape/1.0
http://openid.net/srv/ax/1.0
http://specs.openid.net/extensions/oauth/1.0
http://specs.openid.net/extensions/ui/1.0/lang-pref
http://specs.openid.net/extensions/ui/1.0/mode/popup
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
http://www.idmanagement.gov/schema/2009/05/icam/no-pii.pdf
http://www.idmanagement.gov/schema/2009/05/icam/openid-trust-level1.pdf
http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
},]
If anyone has any idea why this is happening I would really appreciate it. This only occurs on the server so I can't debug it easily.
Thank You.
This suggests that your RP is performing discovery on the original identifier ("yahoo.com") instead of the claimed identifier in the assertion. Can you activate logging and include the entire surrounding log from the server in your question?
Related
I struggle a bit to get Nextcloud to work with Google as SSO provider. I have URL target of the iPd is https://accounts.google.com/o/saml2/idp?idpid=xxxxxxx then I get
403. That’s an error.
Error: app_not_configured_for_user
So following the suggestion here, I changed the url to
https://accounts.google.com/accountchooser?continue=https://accounts.google.com/o/saml2/idp?idpid=xxxxxx
Which redirects me to the google account chooser, but then I get, after selecting my account
null. That’s an error.
Error parsing the request, No SAML message present in request That’s all we know.
Sometimes I am not asked for a user account, so then I get the following from Nextcloud
Account not provisioned.
Your account is not provisioned, access to this service is thus not possible.
What worked for me is to configure Google having these attribute mappings
While on Nextcloud I configure SAML as follows
We have recently migrated to a new hosting environment so have installed a fresh instance of Shibboleth. When we generate sp metadata files, the urls are non-secure (ie http) even though the url used to generate the metadata uses https.
When using the test connection from our own Azure AD system, we see the obvious error: "The reply URL specified in the request does not match the reply URLs configured for the application:"
I have limited knowledge of configuring the system beyond working on shibboleth2.xml and attribute-map.xml so would be very grateful if anyone can point me in the right direction to fix this.
I'm not sure if you managed to configure it but i'm currently working on this as well, and i think i can help.
So the ReplyURL you need to provide in the Azure Portal, is the reply URL that accepts the authentiaction reply message from the identity provider.
In the case of Shibboleth it is:
http[s]://yoursitename/Shibboleth.SSO/Auth/Saml
So if your webpage is for instance:
https://localhost/Foo
The replyURL should be:
https://localhost/Shibboleth.SSO/Auth/Saml
Notice that the page "Foo" is not in the replyURL.
After the authentication the browser should send the IDP reply to https://localhost/Shibboleth.SSO/Auth/Saml, after which Shibboleth should redirect you back to https://localhost/Foo
At least that's the default behaviour.
Hi I am trying to use SSO to authenticate my client's users directly to my website. My client's IDP is Microsoft ADFS and I am using Passport-SAML (https://github.com/bergie/passport-saml) to configure the SSO process.
After getting to a special URL I give my client (example: www.myClient.myCompany.com ), the user (unauthenticated) is as expected redirected to the client login page.
After he enters his credential, he remains stuck in login page BUT the SSO work because the user is authenticated meaning that if he opens a new tab and go to www.myClient.myCompany.com, he will be redirected to my website.
Here the error in ADFS Server Log:
The Federation Service encountered an error while processing the SAML authentication request.
Additional Data
Exception details:
Microsoft.IdentityModel.Protocols.XmlSignature.SignatureVerificationFailedException: MSIS0038: SAML Message has wrong signature. Issuer: 'www.myCompany.co'.
at Microsoft.IdentityServer.Protocols.Saml.Contract.SamlContractUtility.CreateSamlMessage(MSISSamlBindingMessage message)
at Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.Issue(IssueRequest issueRequest)
at Microsoft.IdentityServer.Service.SamlProtocol.SamlProtocolService.ProcessRequest(Message requestMessage)
Thank for your time!
I'm not familiar with Microsoft ADFS nor Passport-SAML, but I when we had signature errors was because the SHA1 fingerpring of the IDp certificate didn't match the one at our end.
We fixed them by making sure the certificate is correctly formatted and then calculating the fingerpring.
Format:
https://developers.onelogin.com/saml/online-tools/x509-certs/format-x509-certificate
Fingerprint:
https://developers.onelogin.com/saml/online-tools/x509-certs/calculate-fingerprint
Hopefully this is your case
Not a Passport-SAML guru but the normal causes of this error with ADFS are:
A signing mismatch - ADFS expects the AuthRequest to be signed and it isn't or vice versa.
The signing certificate installed in this RP has expired or is the wrong one in the sense that it is not the certificate the client is using.
At the RP level, look at:
Get-ADFSRelyingPartyTrust
[-SignedSamlRequestsRequired ]
[-SamlResponseSignature ]
or globally:
Get-ADFSProperties
SignedSamlRequestsRequired
SignSamlAuthnRequests
and check:
Get-AdfsCertificate -CertificateType "Token-Signing"
(following up from ADFS and PingFederate SSO : SAML Message has wrong signature)
We're using a different library and it was a different issue for us (our customer actually had the wrong signature), but during the process of trying to debug, I happened upon this thread that sounds very similar to what you're describing.
The fix is to install this hotfix. Can you check if your customer is on Windows Server 2008 and 2012, has 2843638 or 2843639 installed, and if so, install the hotfix if they haven't already? Just a shot in the dark...
I am using ADFS 3.0 for SSO on SharePoint 2013, I have followed the instructions at http://info.summit7systems.com/blog/beginners-guide-to-claims-based-authentication-ad-fs-3-0-and-sharepoint-2013-part-ii-installing-and-configuring-ad-fs-3-0
but every time I login using the ADFS login page I receive the below error
No strong authentication method found for the request from urn:sharepoint:ontrack.
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.
this is the configuration of authnetication policies
Enabling ADFS tracing will likely give you further insight. I received this error and it related to not having a custom multifactor authentication provider installed on a particular ADFS node.
Is your SharePoint RPT setup for multifactor authentication? If so, you may ensure that the appropriate MFA provider displays and is enabled on the Multi-factor tab.
Does anybody know or have experience on how to do x509 certificate authentication using openAM restful api. Could not find any useful information from official documentation and Google. The last post from a closed openAM issue track indicate the newest API might be able to do certificate authentication. However the detail information is still missing from the link. Any help will be greatly appreciated. Thanks.
First be certain to understand what SSL client auth means and how your infrastructure is setup ... where is the SSL endpoint...
Then read
http://docs.forgerock.org/en/openam/11.0.0/dev-guide/index.html#rest-api-auth-json
it tells you about which parameters you have to provide.
Apart from others OpenAM allows for 'service-based' (authentication chain) and 'module-based' auth.
So either you created an auth chain which has cert auth module configured or you use the module directly.
service-based auth: authIndexType -> service, authIndexValue -> name_of_auth_chain
module-based auth: authIndexType -> module, authIndexValue -> name_of_the_auth_module_instance
Don't forget to look at OpenAM debug logs (debug level set to 'message').