I am trying to integrate a Shibboleth IDPV3.4.1 with my SP which is a server called as ClearPass. I am using the Linux platform of the Shibboleth IDP. I configured the relyingparty.xml, attribute-filter.xml, attribute-resolver.xml,ldap.properties, and also the and uploaded the metadata to the /metadata/sp-metadata.xml also updating the metadata-providers.
I am trying to use the password authentication flow with LDAP, however the issue is that I never get the login page when I initiate the SAML transaction from my SP. I get an error saying "Web Login Service -Stale Request". I have attached the screenshot of the error
Stale Request
I attempt to do a resolver test using the
http://shib.nslab.com:8080/idp/profile/admin/resolvertest?requester=https://chandracppm.nslab.com/networkservices/saml2/sp&principal=chandu
requester "https://chandracppm.nslab.com/networkservices/saml2/sp"
principal "chandu"
attributes
0
name "sAMAccountName"
values
0 "chandu"
and I get the attributes from AD in return, which shows the connection to AD is working.
However the authentication page does not appear from the IDP when I try to access the resource in my SP, I only get the Stale request Error.
The error that I see in the logs/idp-process.log is as follows
2018-12-10 19:26:08,222 - 10.23.20.81 - ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action DecodeMessage: Unable to decode incoming request
org.opensaml.messaging.decoder.MessageDecodingException: Shibboleth Authentication Request message did not contain the providerId query parameter.
at net.shibboleth.idp.saml.profile.impl.BaseIdPInitiatedSSORequestMessageDecoder.getEntityId(BaseIdPInitiatedSSORequestMessageDecoder.java:128)
2018-12-10 19:26:08,223 - 10.23.20.81 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: UnableToDecode
2018-12-10 19:26:08,224 - 10.23.20.81 - DEBUG [org.opensaml.saml.common.profile.logic.DefaultLocalErrorPredicate:143] - No SAMLBindingContext or binding URI available, error must be handled locally
I am new to setting up Shibboleth IDP, not sure what I am missing.
Any inputs would be appreciated
Shibboleth fails to decode the message. This behavior is to be seen if the AuthnReq is being sent to POST endpoint instead of Redirect or vice versa or if any of both endpoints are not configured properly. On UI, the error you will notice for this is "StaleRequest". I got a similar error in idp-process.log file "org.opensaml.messaging.decoder.MessageDecodingException: This message decoder only supports the HTTP GET method". The issue is pertaining to incorrect or misconfigured endpoints.
I was able to get this working by installing an IDP docker image from here
https://docs.google.com/document/d/1qb5XTde1nulCdA_8QUei48CxDj0lQs7ShD622Ze_4II/edit
The authentication flow is working now
Related
I have two web applications configured as SAML Service Providers, using version 1.0.10 of the Spring Security SAML extension. The identity provider is Azure AD.
Single sign-on across both applications works fine. The problem is with single logout (SLO). If I'm logged into both apps in two different browser tabs, and then initiate a logout from one app, that app is logged out as expected, but the logout of the other app fails.
With debug logging enabled, this is the output I get for the second app:
DEBUG [org.springframework.security.web.FilterChainProxy] - Securing GET /saml/SingleLogout?SAMLRequest=lZJfb5swFMW%2fCuLdYGPzxxZBypYtQ20aqVlbaS%2bRgUuKBjbFJs3HLwT1IdJUaW%2f2lY9%2b51yf1Miu7cW9PunRPsLbCMY6%2bWblHmscFoREGHHGJGJJTBHnCUYhl1SWUU1rWrrOMwym0WrlBh52ndyYEXJlrFR2GuEgQAQjQn8TKjATAfcinvxxnc1EaZS0V%2bWrtb0Rvt%2fKcYDW6wcwMJybUnql9sa%2f%2ftN03UklT9CBsv5s2D806tTC4tp1HrTdq%2f2wri0Mt1h2g710rTLimnjljoMSWprGCCU7MMKW4rDe3YspiOgHbXWpWzdLr5GGRfq1SJrJ6BzJzT4jGWu890ZV%2bt14CqwfSYkZqUrEo4IiFsoKceAFimKQAS4JgwT81F%2bYWfowMfKN81MPnbRfw%2bdJU6H6%2blT0868YO63L%2fU%2fnYfwcbrvzcWe%2f3R2L%2fO7Hmv%2b6BPtX%2fXLenrakfvveRo8o3B4anfqLvyxdOnQAM1chVxVcsiMNaREDo6jmkiBWQ4SSuJYowFUZTgcSYJz6%2f1B%2bDm8qmX0A&Signature=H2iMTbizxEM8ooIUfV%2fyZ8zZfkK8J9CXbVako2sPk9EUw1xjRUXfaCUbO3gpsjKvUD61UHEbpOexnMhCtqCJnItC81hIVp9dI2%2bSGqJ3%2fIYFtxDMqVAsP%2fxsEZpL%2f15OkZ0rj0n1nAiU7dT3xC0K5TDtjUWciKqbt0MkJgvKyvkZyjZGjhclfTGo4AJQrEkBVxkw8%2b2Evwgmxpk0taOfhq9sHaiRLzvVAxhCse9GZhbQehxyxtWWNDYt8Ks7JJJR5UDfdszX4E5J2576seSxvop3EeJLlULjjNm3FJZcXoKKAXzA%2bfHqYBYFD9rIyuEXaJsFEC0p8SSAHwKgDOq3PA%3d%3d&SigAlg=http%3a%2f%2fwww.w3.org%2f2001%2f04%2fxmldsig-more%23rsa-sha256
DEBUG [org.springframework.security.web.context.SecurityContextPersistenceFilter] - Set SecurityContextHolder to empty SecurityContext
DEBUG [org.springframework.security.web.FilterChainProxy] - Securing GET /saml/SingleLogout?SAMLRequest=lZJfb5swFMW%2fCuLdYGPzxxZBypYtQ20aqVlbaS%2bRgUuKBjbFJs3HLwT1IdJUaW%2f2lY9%2b51yf1Miu7cW9PunRPsLbCMY6%2bWblHmscFoREGHHGJGJJTBHnCUYhl1SWUU1rWrrOMwym0WrlBh52ndyYEXJlrFR2GuEgQAQjQn8TKjATAfcinvxxnc1EaZS0V%2bWrtb0Rvt%2fKcYDW6wcwMJybUnql9sa%2f%2ftN03UklT9CBsv5s2D806tTC4tp1HrTdq%2f2wri0Mt1h2g710rTLimnjljoMSWprGCCU7MMKW4rDe3YspiOgHbXWpWzdLr5GGRfq1SJrJ6BzJzT4jGWu890ZV%2bt14CqwfSYkZqUrEo4IiFsoKceAFimKQAS4JgwT81F%2bYWfowMfKN81MPnbRfw%2bdJU6H6%2blT0868YO63L%2fU%2fnYfwcbrvzcWe%2f3R2L%2fO7Hmv%2b6BPtX%2fXLenrakfvveRo8o3B4anfqLvyxdOnQAM1chVxVcsiMNaREDo6jmkiBWQ4SSuJYowFUZTgcSYJz6%2f1B%2bDm8qmX0A&Signature=H2iMTbizxEM8ooIUfV%2fyZ8zZfkK8J9CXbVako2sPk9EUw1xjRUXfaCUbO3gpsjKvUD61UHEbpOexnMhCtqCJnItC81hIVp9dI2%2bSGqJ3%2fIYFtxDMqVAsP%2fxsEZpL%2f15OkZ0rj0n1nAiU7dT3xC0K5TDtjUWciKqbt0MkJgvKyvkZyjZGjhclfTGo4AJQrEkBVxkw8%2b2Evwgmxpk0taOfhq9sHaiRLzvVAxhCse9GZhbQehxyxtWWNDYt8Ks7JJJR5UDfdszX4E5J2576seSxvop3EeJLlULjjNm3FJZcXoKKAXzA%2bfHqYBYFD9rIyuEXaJsFEC0p8SSAHwKgDOq3PA%3d%3d&SigAlg=http%3a%2f%2fwww.w3.org%2f2001%2f04%2fxmldsig-more%23rsa-sha256
DEBUG [org.springframework.security.saml.SAMLLogoutProcessingFilter] - Delegating logout processing to super class...
DEBUG [org.springframework.security.saml.SAMLLogoutProcessingFilter] - Processing SAML logout message
DEBUG [org.springframework.security.saml.processor.SAMLProcessorImpl] - Retrieving message using binding urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
INFO [org.opensaml.common.binding.security.BaseSAMLSimpleSignatureSecurityPolicyRule] - Validation of request simple signature succeeded
INFO [org.opensaml.common.binding.security.BaseSAMLSimpleSignatureSecurityPolicyRule] - Authentication via request simple signature succeeded for context issuer entity ID https://sts.windows.net/00000000-0000-0000-0000-00000000/
INFO [org.opensaml.common.binding.security.SAMLProtocolMessageXMLSignatureSecurityPolicyRule] - SAML protocol message was not signed, skipping XML signature processing
DEBUG [org.springframework.security.saml.util.SAMLUtil] - Found endpoint org.opensaml.saml2.metadata.impl.SingleLogoutServiceImpl#76b927ad for request URL https://server.com:443/app2/saml/SingleLogout?SAMLRequest=lZJfb5swFMW%2fCuLdYGPzxxZBypYtQ20aqVlbaS%2bRgUuKBjbFJs3HLwT1IdJUaW%2f2lY9%2b51yf1Miu7cW9PunRPsLbCMY6%2bWblHmscFoREGHHGJGJJTBHnCUYhl1SWUU1rWrrOMwym0WrlBh52ndyYEXJlrFR2GuEgQAQjQn8TKjATAfcinvxxnc1EaZS0V%2bWrtb0Rvt%2fKcYDW6wcwMJybUnql9sa%2f%2ftN03UklT9CBsv5s2D806tTC4tp1HrTdq%2f2wri0Mt1h2g710rTLimnjljoMSWprGCCU7MMKW4rDe3YspiOgHbXWpWzdLr5GGRfq1SJrJ6BzJzT4jGWu890ZV%2bt14CqwfSYkZqUrEo4IiFsoKceAFimKQAS4JgwT81F%2bYWfowMfKN81MPnbRfw%2bdJU6H6%2blT0868YO63L%2fU%2fnYfwcbrvzcWe%2f3R2L%2fO7Hmv%2b6BPtX%2fXLenrakfvveRo8o3B4anfqLvyxdOnQAM1chVxVcsiMNaREDo6jmkiBWQ4SSuJYowFUZTgcSYJz6%2f1B%2bDm8qmX0A&Signature=H2iMTbizxEM8ooIUfV%2fyZ8zZfkK8J9CXbVako2sPk9EUw1xjRUXfaCUbO3gpsjKvUD61UHEbpOexnMhCtqCJnItC81hIVp9dI2%2bSGqJ3%2fIYFtxDMqVAsP%2fxsEZpL%2f15OkZ0rj0n1nAiU7dT3xC0K5TDtjUWciKqbt0MkJgvKyvkZyjZGjhclfTGo4AJQrEkBVxkw8%2b2Evwgmxpk0taOfhq9sHaiRLzvVAxhCse9GZhbQehxyxtWWNDYt8Ks7JJJR5UDfdszX4E5J2576seSxvop3EeJLlULjjNm3FJZcXoKKAXzA%2bfHqYBYFD9rIyuEXaJsFEC0p8SSAHwKgDOq3PA%3d%3d&SigAlg=http%3a%2f%2fwww.w3.org%2f2001%2f04%2fxmldsig-more%23rsa-sha256 based on location attribute in metadata
DEBUG [org.springframework.security.saml.SAMLLogoutProcessingFilter] - Received logout request is invalid, responding with error
org.springframework.security.saml.SAMLStatusException: No user is logged in
at org.springframework.security.saml.websso.SingleLogoutProfileImpl.processLogoutRequest(SingleLogoutProfileImpl.java:175) ~[spring-security-saml2-core-1.0.10.RELEASE.jar:1.0.10.RELEASE]
at org.springframework.security.saml.SAMLLogoutProcessingFilter.processLogout(SAMLLogoutProcessingFilter.java:181) [spring-security-saml2-core-1.0.10.RELEASE.jar:1.0.10.RELEASE]
at com.tessella.sdb.core.security.authentication.saml.SamlCustomLogoutProcessingFilter.processLogout(SamlCustomLogoutProcessingFilter.java:52) [WebAppSecurity-6.6.0-bugfix_SUPPORT-1608-SNAPSHOT.jar:?]
at org.springframework.security.saml.SAMLLogoutProcessingFilter.doFilter(SAMLLogoutProcessingFilter.java:107) [spring-security-saml2-core-1.0.10.RELEASE.jar:1.0.10.RELEASE]
...
In Azure AD, the Front-channel logout URL for app2 is set as https://server.com/app2/saml/SingleLogout, so it looks like the endpoint is called & the HTTP-Redirect binding is used.
However, in SAMLLogoutProcessingFilter, for the line:
Authentication auth = SecurityContextHolder.getContext().getAuthentication();
auth is returned as null, i.e. there's no existing user session and so the logout fails. I've seen reports of this happening elsewhere with WSO2 as the SAML IdP, when the HTTP POST binding is used, but with Azure AD, my understanding is that this should be a front-channel request using the HTTP-Redirect binding.
Has anyone got Single Logout to work successfully using Azure AD as the IdP with the Spring SAML extension? Are there any configuration changes required either in the SP or IdP?
Any advice on what I need to do would be gratefully received. Thank you.
OK, so I found the answer. We're using the Apache web server as a reverse proxy in front of the apps, and this was setting same-site on the session cookie to Lax. Since the Logout request was coming from the SAML IdP, the session cookie was being removed. If same-site is set to None instead, the session cookie is attached, and the call to:
SecurityContextHolder.getContext().getAuthentication()
returns the valid authentication credentials.
I am building a spring-boot application which uses google/facebook oauth2 authentication. The application configurations set are as follows:
#Google
spring.security.oauth2.client.registration.google.clientId=<googleClientId>
spring.security.oauth2.client.registration.google.clientSecret=<googleClientSecret>
spring.security.oauth2.client.registration.google.redirectUri={baseUrl}/oauth2/callback/{registrationId}
spring.security.oauth2.client.registration.google.scope=email,profile
#Facebook
spring.security.oauth2.client.registration.facebook.clientId=<fbClientId>
spring.security.oauth2.client.registration.facebook.clientSecret=<fbClientSecret>
spring.security.oauth2.client.registration.facebook.redirectUri={baseUrl}/oauth2/callback/{registrationId}
spring.security.oauth2.client.registration.facebook.scope=email,public_profile
spring.security.oauth2.client.provider.facebook.authorizationUri=https://www.facebook.com/v13.0/dialog/oauth
spring.security.oauth2.client.provider.facebook.tokenUri=https://graph.facebook.com/v13.0/oauth/access_token
spring.security.oauth2.client.provider.facebook.userInfoUri=https://graph.facebook.com/v13.0/me?fields=id,first_name,middle_name,last_name,name,email,verified,is_verified,picture.width(250).height(250)
For google, this is working well - the application has an authorization rest controller which redirects to the google auth end point. After logging in, I can see a code is returned and sent to a redirect URI {baseUrl}/ouath2/callback/google, which is exchanged for a token which is in turn parsed and used to construct a universal application-level Oauth2 bearer token (for use in my shared APIs etc).
For facebook, I am attempting a similar setup. The initial redirect works, and user is directed to a facebook login page with equivalent client_id / redirect uri parameters set:
https://www.facebook.com/v3.0/dialog/oauth
?response_type=code
&client_id=<fbClientId>
&scope=email+public_profile
&state=<state>
&redirect_uri=https%3A%2F%2F192.168.50.150.nip.io%3A8300%2Foauth2%2Fcallback%2Ffacebook
&ret=login
&fbapp_pres=0
&logger_id=e1036c5a-ac6e-448c-ab8g-655727eae993
&tp=unspecified
&cbt=1643459835928
&ext=1645463198
&hash=AeJog6HeUz9jlsDRQQo
However, when the code is obtained after login and sent to the redirect uri {baseUrl}/ouath2/callback/facebook, there is an error returned when my application attempts to access the FB User Info resource server:
I don't have any traffic capture from my backend to the FB User Info URI, so I can't see exactly what's being sent, but the response I get back is a server error:
[invalid_user_info_response] An error occurred while attempting to
retrieve the UserInfo Resource: Error details: [UserInfo Uri:
https://graph.facebook.com/v3.0/me?fields=id,first_name,middle_name,last_name,name,email,verified,is_verified,picture.width(250).height(250),
Error Code: server_error]
Are there any known issues with the graph.facebook.com end points?
I've downloaded the code from Spring's Get Started Guide - Accessing Twitter Data the https://spring.io/guides/gs/accessing-twitter/ .
I set up my credentials in application.properties and made no other changes. I run the app, and when it attempts to connect to Twitter, it fails with an exception on ConnectController line 240:
ResourceAccessException:
org.springframework.web.client.ResourceAccessException: I/O error on
POST request for "https://api.twitter.com/oauth/request_token":cannot
retry due to server authentication, in streaming mode; nested
exception is java.net.HttpRetryException: cannot retry due to server
authentication, in streaming mode
I have checked that the credentials are being read by the app. They are valid - I use them to connect with another application I've written with twitter4j, although in that case I use a Token and Token Secret in addition to the Consumer Key and Consumer Secret.
Any ideas?
Thanks
I had exactly the same issue as you : it happened because I did not set my callback URL in the twitter setting.
Just check in your twitter app settings that the callback field is set (I used the same URL as the website field).
I am using Spring Security SAML to have my application act as an SP. I was able to have the end-to-end solution done. However, I am facing a problem when the user wants to access the application using more than one URL. I have configured my SP metadata with the Assertion Consumer Service URL to be mywebsite:8080/myapp/saml/SSO.
The user can also access the application through the full domain name
mywebsite.fulldomainname:8080/myapp/
If the user accesses the second URL, The SP application will redirect to the IDP which will return the first URL which will fail giving this message:
InResponseToField of the Response doesn't correspond to sent message
Even if I used the EmptyStorageFactory, it will still fail in the AbstractProfileBase.verifyEndpoint
How can I fix that?
Part of the SAML's security model is verification of the intended endpoint - where IDP wants to deliver a SAML message - and endpoint where SP actually received the message - the two need to match. Therefore your SP metadata needs to include correct information about the URL where it expects SAML messages to be delivered. You will encounter errors in the verifyEndpoint in case the SP metadata has different URL than where your IDP delivers the message.
Spring SAML allows you to define multiple different metadata (with different URLs) for the same deployment. So you can solve your problem by generating one metadata for mywebsite:8080/myapp, the other for mywebsite.fulldomainname:8080/myapp/ and importing both to your configuration. Each of those will have to have a different entityId and will also need to be separately imported to your IDP.
You can find more details in chapter 7.2 of the Spring SAML manual - pre-configured metadata.
I am implementing shibboleth IDP and SP. I have installed in my machine and tested it with testshib.org , both(IDP&SP) are working fine.
I am trying to use my own IDP with my SP.
Once I access the protected resource, SP redirects to the IDP login page correctly, after authentication is successful, it is redirected to the SP with the SAML encrypted response (With the servlet status code 500) Which shows the following error ,
"opensaml::FatalProfileException at (https://myip.address/Shibboleth.sso/SAML2/POST)
A valid authentication statement was not found in the incoming message."
I checked the native log which shows the following message.
"2013-08-29 20:22:36 ERROR Shibboleth.Listener [28868] shib_handler: remoted message returned an error: A valid authentication statement was not found in the incoming message.
2013-08-29 20:22:36 ERROR Shibboleth.Apache [28868] shib_handler: A valid authentication statement was not found in the incoming message."
How can I rectify this problem?
What do the IdP logs show for the corresponding authentication attempt? You may need to elevate the log levels to DEBUG for IdP, OpenSAML and/or LDAP (conf/logging.xml) to get sufficiently descriptive results.