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...
Related
I configured a SAML identity provider in keycloak by importing metadata provided by Microsoft ADFS.
I could see the option of IdP on my client login page for login.
After clicking on that on that button it redirects to external identity provider login page.
After login, I get success with a SAMLResponce. (Checked with SAML tracer).
The page is redirected to IDP redirect URL.
After redirecting page shows me "invalidFederatedIdentityActionMessage"
I saw the docker logs it gives me ---
23:58:09,035 WARN [org.keycloak.events] (default task-181) type=IDENTITY_PROVIDER_RESPONSE_ERROR, realmId=rak-development, clientId=null, userId=null, ipAddress=172.18.0.4, error=invalid_saml_response, reason=invalid_destination
Can you please help what I am doing wrong.
This happens when you configure the Identity Provider to 'Validate Signature'. When you turn that switch on, Keycloak validates the SAML response against the text in 'Validating X509 Certificates'. That field should contain a valid certificate from your Identity Provider; in this case the App registration in Microsoft.
Try turning the 'Validate Signature' switch off to see if that removes the error. Then you can debug the certificate value.
I had a similar problem and it turned out to be a misconfiguration of the F5 proxy/firewall. It sent the wrong header "X-Forwarded-Proto: http" instead of "X-Forwarded-Proto: https". Maybe this can help.
I found a solution. For me, the issue was that I needed to set the PROXY_ADDRESS_FORWARDING=true envvar. I had already done that but I typoed the name.
I am using the AWS ALB which sets the X-Forwarded headers. I know those are also needed.
I have created a SAML 2.0 App on okta and have finished all the configurations. I then attempt to do an authorization from my application, by doing a redirect to the okta idp ->
http://www.okta.com/(okta created token)?SAMLRequest=(encoded saml xml)
The redirect returns a 404. When I go to my admin okta console I don't see any logs for the failed attempt, which i guess makes sense since it is returning a 404, but i don't know how to figure out what is causing the 404.
Is there a way to figure out what is causing the issue?
Install SAML tracer browser extensions and try it again to confirm the SAML Response is being decoded correctly.
To address your question "Is there a way to figure out what is causing the issue?", I have repeated your SAML 2.0 authentication steps suggested by your post.
The following responses and answer will help you to "figure out what is causing the issue".
(1) Quote your post "I have created a SAML 2.0 App on okta and have finished all the configurations. I then attempt to do an authorization from my application, by doing a redirect to the okta idp ->
http://www.okta.com/(okta created token)?SAMLRequest=(encoded saml xml)"
Response:
(I) I have created a SAML 2.0 SP App on okta and have finished all the configurations as you did.
(II) I then attempt to do an authorization from my SAML SP application, by doing a redirect to the okta idp as you did.
(III) Submit the username/password of local Okta user account (e.g., john.doe#example.com) to proceed with SAML authentication.
(2) Quote your post "The redirect returns a 404. When I go to my admin okta console I don't see any logs for the failed attempt, which i guess makes sense since it is returning a 404, but i don't know how to figure out what is causing the 404."
Response:
(I) In my experiment, the redirect returns the following error message instead of a 404 error.
Sorry, you can't access SAML 2.0 SP demo because you are not assigned this app in Okta.
If you're wondering why this is happening, please contact your administrator.
If it's any consolation, we can take you to your Okta home page.
(II) Then "I go to my admin okta console" as suggested by your post,
navigate to Reports > System Log, I saw the log below.
Event Info Targets
User attempted unauthorized access to app SAML 2.0 SP demo (AppInstance)
FAILURE :
(3) Quote your question "Is there a way to figure out what is causing the issue?"
Answer:
I summarize the four (4) potential root causes of your SAML authentication failure. The top #1 potential root cause is that you uploaded the wrong okta IdP metadata file into your SAML 2.0 SP app server (see the detailed description below).
(I) Potential Issue #1:
The root cause of my issue is that my local okta user account was NOT assigned to access this SAML 2.0 App.
Resolution:
(a) Navigate to Applications > SAML 2.0 App, then click Assign > Assign to People,
(b) On the pop-up dialog box, select the local Okta user accounts (e.g., John Doe (john.doe#example.com)), click Assign, click Save and Go Back, then click Done.
(c) Repeated the above SAML 2.0 authentication steps again, I was redirected back and logged in to SAML 2.0 App successfully.
(II) Potential Issue #2:
Three (3) potential root causes of this issue are that
(a) you did NOT fill in all the correct SAML SP information of your SAML 2.0 SP app on okta.
(b) or you did NOT upload the okta IdP metadata file into your SAML 2.0 SP app server
(c) or you uploaded the wrong okta IdP metadata file into your SAML 2.0 SP app server (this is the highest probability for bringing your 404 failure, because unlike most of SAML IdPs which create only one IdP metadata file for all SAML SP apps, okta create different IdP metadata files for different SAML SP apps).
Resolution:
Regarding to root cause (II.a): You need to ensure that the following SAML SP information should be the exactly the same as the SAML SP metadata of your SAML 2.0 SP app when you create new SAML 2.0 app.
Single sign on URL should come from your SAML SP metadata, e.g.,
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-saml-sp-app-URL/SAML2/POST" index="1"/>
Audience URI (SP Entity ID) should also come from your SAML SP metadata, e.g.,
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="_random-string" entityID="https://your-saml-sp-app-URL/SAML2/Metadata">)
The sample SAML Settings of SAML 2.0 SP app on okta
Navigate to Applications > your SAML 2.0 App > general > SAML Settings
Single Sign On URL https://your-saml-sp-app-URL/SAML2/POST (i.e., your SAML SP AssertionConsumerService)
Recipient URL https://your-saml-sp-app-URL/SAML2/POST (i.e., your SAML SP AssertionConsumerService)
Destination URL https://your-saml-sp-app-URL/SAML2/POST (i.e., your SAML SP AssertionConsumerService)
Audience Restriction https://your-saml-sp-app-URL/SAML2/Metadata (i.e., your SAML SP entity ID)
Default Relay State
Name ID Format Unspecified
Response Signed
Assertion Signature Signed
Signature Algorithm RSA_SHA256
Digest Algorithm SHA256
Assertion Encryption Unencrypted
SAML Single Logout Disabled
authnContextClassRef PasswordProtectedTransport
Honor Force Authentication Yes
SAML Issuer ID http://www.okta.com/${org.externalKey}
Regarding to root causes (II.b) and (II.c): You need to upload the correct okta IdP metadata into your SAML 2.0 SP app server.
Note that okta creates different okta IdP metadata files for your different SAML 2.0 SP apps.
Navigate to Applications > your SAML 2.0 App > Sign On
Identity Provider metadata is available if this application supports dynamic configuration.
Click Identity Provider metadata to download the okta IdP metadata for your SAML 2.0 SP app.
Log in to your SAML 2.0 SP app, upload the okta IdP metadata into your SAML 2.0 SP app, and then complete the configuration to store the okta IdP information on your SAML 2.0 SP app server.
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.
SSOCircle provides a ready to use Identity Provider according to their website. I wanted to simulate SAML SSO and integrate it in sample Liberty for Java application in bluemix.
What I did so far:
Downloaded SSOCircle Public IDP Metadata from "Manage Metadata". Uploaded it into the bluemix SSO service via the upload file button and entered https://idp.ssocircle.com/sso in the textbox under "Step 1" in the SAML Enterprise setup.
Downloaded SAML metadata under "Step 2" in the SAML Enterprise setup and imported it in SSOCircle. The FQDN that I used is: https://ssocruzgstest-8iotczj2sk-cabc.iam.ibmcloud.com.
Edit** Changed URL to https://idp.ssocircle.com/sso/idpssoinit?metaAlias=/ssocircle&spEntityID=https://ssocruzgstest-8iotczj2sk-cabc.iam.ibmcloud.com/idaas/mtfim/sps/idaas/saml20 as recommended by Martin
After integrating. I pointed my browser to https://cruzgsjava1.mybluemix.net then clicked "Sign in with SAML Enterprise".
I got redirected to https://idp.ssocircle.com/sso/UI/Login?module=peopleMembership&goto=https%3A%2F%2Fidp.ssocircle.com%2Fsso%2Fidpssoinit%3FmetaAlias%3D%2Fssocircle%26spEntityID%3Dhttps%3A%2F%2Fssocruzgstest-8iotczj2sk-cabc.iam.ibmcloud.com%2Fidaas%2Fmtfim%2Fsps%2Fidaas%2Fsaml20. I logged in and encountered an error
Your URL is wrong. I have not seen clear documentation on ssocircle.com, but I found some samples from which I could deduce the (hopefully) right URL pattern. This is what I use for testing:
https://idp.ssocircle.com/sso/idpssoinit?metaAlias=/ssocircle&spEntityID=<your SP entity ID>;
You can find out your SP entity ID by downloading the service provider metadata in step 2 and inspect the attribute "entityID" of the root element "md:EntityDescriptor".
The SSOCircle URL is correct. The error happens at the bluemix site. According to IBM knowledge center FBTSML236E says that the trace log will indicate the operation failed.
Most probably the validation of the assertion signature is failing. SSOCircle signing certificate itself is not self-signed but is signed by its own CA.
It could be the case that bluemix is validating the whole certificate chain and for that reason needs the CA certificate. You can get it from the SSOCircle web site after logging in and then under 'My certificate status' you'll find a link to the CA certificate.
If that does not solve the problem. Check with IBM how the SAML response is validated. SSOCircle public IDP by default signs the SAML assertion. It could potentially be that bluemix has different requirements (e.g. signing the SAML response)
My knowledge of these systems is not large so please forgive me if I am asking dumb questions.
I hope to achieve the following:
Idp (AD FS 2.0) -> SAML 2.0 -> Sp (simpleSAMLphp)
*I don't need anything more fancy than to simply authenticate a user.
I have attempted to configure Windows Server 2008 with AD FS 2.0 (domain A) as an Identity provider and have it handle authentication requests from a service provider on a different domain (created using simpleSAMLphp (domain B)).
The AD FS 2.0 Management application allows me to add raw meta XML from the SP to configure the idp. And my SP has the facility to do the same. So I figure that If I setup the idp (AD FS 2.0) correctly then I will simple just have to make the SP interpret the metadata of the idp.
Currently I feel that I am close to a solution (but then again I am probably wrong!). Currently it seems everything is find right up to the point when the Idp asks for your login credentials, and I enter my credentials, it appears that the session has started, but I get a 'Not Authorized - HTTP Error 401. The requested resource requires user authentication.' message after entering the correct login credentials.
Could someone please explain how to fix this? or if it's quicker a step by step setup to make AD FS 2.0 authenticate using SAML 2.0 for simply authenticating a username and password.
Thankyou in advance for any hints!
Have you established a claims provider trust within ADFS 2.0 management? Your system needs to accept claims-bearing tokens from a trusted claims provider. That is, whatever STS -- "Security Token Service" -- you have in front of your user repository. ADFS can both a "Relying Party" -- RP -- or a STS. You need both a relying party and a STS.
Check out Eugenio Pace's MSDN blog for more details:
http://blogs.msdn.com/b/eugeniop/archive/tags/federated+identity/