i'm trying Okta quick start for Java tomcat SAML, I am very new to this topic.
When I start my test application I do see a link to Okta IDP, after clicking "Start single sign-on" button i am being redirected to Okta address with info "Sining in to SAML - Test" (my Okta test name) after that I'm again being redirected to my application with:
Error
Error validating SAML message
after that there is a stack trace with
Caused by: org.opensaml.common.SAMLException: Response doesn't have any valid assertion which would pass subject validation
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:229)
at org.springframework.security.saml.SAMLAuthenticationProvider.authenticate(SAMLAuthenticationProvider.java:82)
... 27 more
Caused by: org.opensaml.common.SAMLException: Local entity is not the intended audience of the assertion in at least one AudienceRestriction
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAudience(WebSSOProfileConsumerImpl.java:506)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertionConditions(WebSSOProfileConsumerImpl.java:458)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOProfileConsumerImpl.java:303)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:214)
... 28 more
What am I missing? What am I doing wrong?
Thanks for all your help Zack.
The entity ID of your Spring SAML Service Provider doesn't match Destination element in the SAML response from Okta. Compare the two values and fix the value on either Spring SAML or Okta side.
Same issue when deploying Spring Boot app in Azure Container Instance and using Okta SAML. saml.sp=http://fqdn-of-my.domain.com:8082/saml/metadata, FQDN resolved by an AWS hosted DNS zone A record, the URL itself is accessible and downloads the spring_saml_metadata.xml.
Caused by: org.opensaml.common.SAMLException: Local entity is not the intended audience of the assertion in at least one AudienceRestriction
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAudience(WebSSOProfileConsumerImpl.java:542)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertionConditions(WebSSOProfileConsumerImpl.java:494)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOProfileConsumerImpl.java:339)
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:250)
... 53 more
Update after 30 minutes: I noticed that the error went away after a rebuild and redeploy of the app!!
With
saml.sp=http://fqdn-of-my.domain.com:8082/saml/metadata in Spring application.properties, the SP Metadata available at the same URL was originally the below, giving error:
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="http___localhost_8082_saml_metadata"
entityID="http://localhost:8082/saml/metadata">
A rebuild and redeployment of the app with Metadata as below resulted in successful handshake:
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
ID="http___fqdn-of-my.domain.com_8082_saml_metadata"
entityID="http://fqdn-of-my.domain.com:8082/saml/metadata">
I am pretty sure I had the property correctly set even when it was giving error. But anyway, a rebuild of the Dockerized Spring app and redeploy of the same in Azure ultimately fixed the problem.
Related
I have tried using the sso url as mentioned "Single Signon Service"https://auth.pingone.asia/{env}/saml20/idp/sso , and issuer as https://auth.pingone.asia/{env}. but getting ErrorCode: INVALID_ISSUER - Unable to find application for spEntityId: 'https://auth.pingone.asia/{env}' in environment {env}.
Please help me to understand where exactly I have wrong configuration.
Check if you have created a SAML Application, if not, try creating it with https://apidocs.pingidentity.com/pingone/platform/v1/api/#post-create-application-saml-protocol
Note: acs url is the place where you want PingIdentity to redirect after login authentication is completed. You will get a SAMLRespose also posted there.
(OR) You can create SAML application directly from the PingIdentity console itself by selecting Add Application, Select SAML as type, and Set Manual Saml configuration by specifying entity id (something unique) and ACS url.
Go to ping console dashboard, and check the Entity ID of the application, it should match with your AuthnRequest saml:Issuer
Example if your dashboard is like this with Entity ID "test",
then your AuthnRequest should look like this:
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="test"
Version="2.0"
IssueInstant="2022-09-19T16:46:59">
<saml:Issuer>test</saml:Issuer>
</samlp:AuthnRequest>
Note the line: <saml:Issuer>test</saml:Issuer>
I am trying to setup saml sso configuration for my application which is deployed in websphere.
Idp- Azure AD
SP - Websphere application server when my target application deployed
Done TAI configuration as per the Ibm document . But when I hit the test button from idp I could see the saml response in network tab. but i couldn't login to my application and also didn't get any trace related to saml in log files also however i have enabled logs for saml in Troubleshoot. My doubt is sometimes am getting trace which are related to TAI during server stop. For each request should i be getting TAI trace ? and why my saml response not getting intercepted in TAI. How exactly the interception happen with saml response and how do we get to know that saml response got validated.
[15/4/21 16:18:42:855 IST] 00000096 TrustAssociat A SECJ0121I: Trust Association Init class com.ibm.ws.security.web.saml.ACSTrustAssociationInterceptor loaded successfully
acs url -> https://localhost:/browserTest (which is my actual target application url)
metadata and signing certificates also imported correctly.
Thanks for your help.
The acs URL has format like this:
https://<hostname>:<sslport>/samlsps/<any URI pattern string>
if you want to use your application URL
https://localhost:/browserTest
as acs URL, this UR must be able to accept HTTP POST.
I need help in implementing Single Logout.I'm able to implement SSO service successfully.But SLO service is not working.
I got RequestDenied status code after performing logout on my OWIN based asp.net MVC application.
<saml2p:LogoutRequest
Destination="https://sap-client.accounts.ondemand.com/saml2/idp/slo/sap-client.accounts.ondemand.com"
ID="idb2d655f7174f465696a433c75a717b46" IssueInstant="2019-08-03T02:16:03Z" Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:Issuer>https://sp.domain.com/Saml2</saml2:Issuer>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">xxx#xxx.com</saml2:NameID>
<saml2p:SessionIndex>S-SP-6aff8686-a642-4381-8ab3-0f18c6815ffe</saml2p:SessionIndex>
<LogoutResponse Destination="https://sp.domain.com/Saml2/Logout" ID="S0e6a2f99-2517-4326-a8ce-2ede2dfe1bfa" InResponseTo="idb2d655f7174f465696a433c75a717b46" IssueInstant="2019-08-03T02:16:04.933Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://www.w3.org/2001/04/xmlenc#" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#">
<ns2:Issuer>sap-client.accounts.ondemand.com</ns2:Issuer>
<Status>
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" />
</StatusCode>
<StatusMessage>Identity Provider could not process the logout message received.</StatusMessage>
</Status>
Here is Owin log
Sustainsys.Saml2.Owin.Saml2AuthenticationMiddleware Error: 0 : Error in Saml2 for /Saml2/Logout
Sustainsys.Saml2.Exceptions.UnsuccessfulSamlOperationException: Idp returned status "Requester", indicating that the single logout failed. The local session has been successfully terminated.
at Sustainsys.Saml2.WebSso.LogoutCommand.HandleResponse(UnbindResult unbindResult, StoredRequestState storedRequestState, IOptions options, Uri returnUrl)
at Sustainsys.Saml2.WebSso.LogoutCommand.Run(HttpRequestData request, String returnPath, IOptions options)
at Sustainsys.Saml2.Owin.Saml2AuthenticationHandler.d__4.MoveNext()
ProcessId=14888
DateTime=2019-08-04T06:16:22.3060366Z
Thank you in advance.
The Idp returns an error. You should check the logs on the Idp to get more information on why.
It might also be worth using SAML dev tools for Chrome to check the actual messages, there might be more status codes embedded in the response.
One reason that this might occur is if you have a long lived session in your application that extends beyond the life time of the Idp session. With owin based applications where the external login session is typically swapped to an application login session this might happen - the session life time limit is lost in the swap done in ExternalLoginCallback.
I have created a Springboot Restful Application for my organization.
I have a requirement to,
Implement SAML/SSO with IdP (ADFS2.0),
Deploy the application on Google's App Engine (GAE).
I have managed to deploy the Springboot Application on GAE (with SAML) successfully.
And I have tested the SAML/SSO with a Mock version of IdP (something similar to SSO-Circle) on localhost and it works smoothly.
But, When I deploy the Application on GAE (with either Mock version of IdP or a QA version of IdP), I started getting
InResponseToField doesn't correspond to sent message
, and I did find a fix for it in the Spring docs here.
But,
I fail to understand, even after intense debugging, why I get that error in the first place (although I get a different error later after applying the fix, which I will describe later further).
Much confusing part is when I had a look at the App Engine Logs, I found out,
that on making /saml/login call, the log trace shows
HttpSessionStorage : Storing message a3bbxxxx6c17 to
session BXtxxxx1CCw
and then when IdP redirects back to the Application on the endpoint /saml/SSO, the log throws an error,
HttpSessionStorage : Message a3bbxxxx6c17 not found in
session BXtxxxx1CCw
along with the exception
SAMLException: InResponseToField of the Response doesn't correspond to
sent message a3bbxxxx6c17
I also cross verified the SAML request(XML) that goes out from Application to the IdP and SAML response(XML) which comes back from the IdP to the Application and both of them have the a3bbxxxx6c17 message.
So, why Springboot is confused on GAE and works fine with localhost.
Also, when I do what the spring docs says, "checking of the InResponseToField can be disabled by re-configuring the context provider", I notice a loop happening, i.e.,
/saml/login -> 2. /saml/SSO -> /landing -> 3. /saml/SSO -> /landing -> 4. /saml/SSO -> /landing -> 5. /saml/SSO -> /landing .... and so on, until the IdP rejects the request saying too many request in fraction of time.
I don't understand why this is happening either, but my hypothesis is this can be due to the above issue.
Any thoughts?
Solved the issue by adding an extra configuration.
The fact that this happens is Spring is not aware of the sessions on App Engine (GAE), and all we need to do is tell spring about it.
#Configuration
#EnableWebSecurity
//Needed for Spring to know about the HttpSession
#EnableSpringHttpSession
#EnableGlobalMethodSecurity(securedEnabled = true)
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
//And this bean
#Bean
public MapSessionRepository sessionRepository() {
return new MapSessionRepository();
}
// all other configurations
}
We have an OpenSSO (OpenAM) instance set up at our end to work as a Service Provider (SP). It's been working well so far in an SP Initiated SSO scenario, however, I recently had to set it up for an IDP initiated scenario and am unable to get it to work successfully. To explain, in this scenario, the IDP would like to send the SAMLResponse directly to the Assertion consumer service at my end and our OpenAM instance should be able successfully digest the response and send the user to our underlying application. My questions are:
Is there any other configuration required in this scenario except for exchanging/uploading the metadata between the IDP and us (SP)?
Can I upload the metadata of the iDP in the same COT as the other IDPs that are currently working in the SP Initiate Scenario? Or should there be a new COT for each IDP provider?
What URL should I provide to the IDP to send the SAMLResponse to? Is it the AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" from our metadata? I tried this a few days back and OpenAM reported an error - "this is not the right consumer service for this request" or something.
I got an answer for this on an OpenAM forum -
http://lists.forgerock.org/pipermail/openam/2012-August/007872.html