I am struggling to understand why in certain cases a web application repeatedly sends AuthnRequest requests to the IdP. Is this behaviour configurable on the application side or on the IdP side? Does Spring SAML application send the AuthNRequest only once when logging in or can it send it also later? I checked the spring-security-saml source code and the method 'sendAuthenticationRequest' is executed only during SSO initialization in org.springframework.security.saml.SAMLEntryPoint#initializeSSO so I am confused.
Here is some background: application sends keep-alive requests every 10 minutes, each of those requests triggers sending AuthNRequest:
2020-10-19 12:01:50,335 INFO SAMLDefaultLogger.java:129 - log - AuthNRequest;SUCCESS;10.3.139.13;app1;https://sts.windows.net/acb2b37b-5da0-189b-9b83-0014b27a7c18/;;;
2020-10-19 12:11:50,333 INFO SAMLDefaultLogger.java:129 - log - AuthNRequest;SUCCESS;10.3.139.13;app1;https://sts.windows.net/acb2b37b-5da0-189b-9b83-0014b27a7c18/;;;
2020-10-19 12:21:50,361 INFO SAMLDefaultLogger.java:129 - log - AuthNRequest;SUCCESS;10.3.139.13;app1;https://sts.windows.net/acb2b37b-5da0-189b-9b83-0014b27a7c18/;;;
How long is the session between the SP and the browser? If the SP session has expired it would trigger an authentication request.
Is the application configured to require authentication even if an IDP session exists?
E.g saml.sso.profile-options.force-authn=true.
Related
We are using SAML 2.0 with ADFS hosted on Windows Server 2016. SSO is working. Users can successfully log into the ADFS identity provider and are redirected to the relying party and the SAML token is decrypted, assertions are read, and the user is successfully logged in. So far, so good.
SLO with ADFS and SAML 2.0 is not as clear. The OASIS specification (https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) includes the following guidance on creating SAML 2.0 LogoutRequest. On page 33, the process for issuing the LogoutRequest is described as follows:
LogoutRequest issued by Session Participant to Identity Provider
In step 1, the session participant initiates single logout and terminates a principal's session(s) by
sending a LogoutRequest message to the identity provider from whom it received the
corresponding authentication assertion. The request may be sent directly to the identity provider
or sent indirectly through the user agent.
How is this step applied to ADFS? Specifically:
What endpoint on ADFS should the LogoutRequest be sent to?
If it is a POST request should the XML be submitted in the body? If not, how should it be packaged?
The majority of documentation we have found online that discusses SLO on ADFS uses WS-Federation rather than SAML 2.0.
ADFS's endpoint for SAML SLO is https://[your-adfs]/adfs/ls/
And yep, usually it's a POST containing the <samlp:LogoutRequest ... in its body.
See this answer for much more details.
I have one SP and one IDP using Keycloak.
I'm using SAML protocol and I can successfully login and logout when the request is initiated by the SP.
But when connected as an admin in Keycloak I logout an user from his session no request are sent to the SP.
The session is indeed terminated on the IDP side but not on the SP side.
Because of that the user on the SP can still use the application.
I can't see any option in client configuration for that.
Has anyone made IDP initiated log out in SAML works with keycloak ?
Could you give me some directions ?
Thank you for your time.
After some other research this is not a feature of Keycloak.
https://www.keycloak.org/docs/2.5/server_admin/topics/sessions/administering.html
Quoting the docs
Only certain clients are notified of this logout event, specifically clients that are using the Keycloak OIDC client adapter. Other client types (i.e. SAML) will not receive a backchannel logout request.
I had the same issues using keycloak saml broker. It turned out that enabling back-channel logout (disabling front-channel logout) in keycloak client configuration solved my problem.
I am using 4.8.0.Final
I'm implementing an SSO authentication flow using SAML for a web server running tomcat. Everything is working ok when using POST or Redirect bindings, but from what I've read to support the SAML authentication in front of a REST API I need to also configure and use an ECP profile.
First correct me if I'm wrong but the ECP flow should be like this:
Client accesses the SP REST API
Client knows he needs to authenticate so he sets up the required ECP headers (Accept: application/vnd.paos+xml and PAOS: urn:liberty:paos:2003-08;urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp)
SP sees client is not authenticated and returns a SOAP Envelop containing PAOS Request.
The client is responsible to send this to the appropriate IdP on its ECP consumer service.
The IdP challenges the client for authentication
The IdP returns a response in the form of another SOAP Envelop, containing the saml Response in its body
The client must send this response to SP's ECP/SOAP assertion consumer service
The problem is all of this works until step 6. On this step I have the problem, that the Body of the response envelop contains a Destination attribute, which points to the POST assertion consumer service of the SP. This destination attribute is set by keycloak and mismatches the actual ECP service that I want to send the response to. The SAML library we are using is opensaml and it checks the request URI against this Destination attribute and if they do not match it throws an exception org.opensaml.xml.security.SecurityException: SAML message intended destination endpoint did not match recipient endpoint.
I understand why this exception is thrown, but cannot understand how I can configure Keycloak with the ECP/SOAP service of the SP. In Keycloak's admin console I can only configure the URLs for SSO POST/Redirect and SLO POST/Redirect, but nothing about ECP.
I'm currently in the process of configuring another IdP, but I would really like to make sure that Keycloak can also be a supported server for our solution.
Can't you just read the paos:Request responseConsumerURL and post the idp response to that url?
At least, that's how I managed to do it.
We would like to implement such additional configuration for SSO in our organization:
Web application (with SpringSaml) --- WSO2 IS 5.0.0 --- SimpleSaml as IDP for WSO2 IS.
Our working SSO configuration is:
Other Services --> SimpleSaml
Almost all works OK. But if I login to WSO2 IS from my application and from other service I login to SimpleSaml and that other service send LogoutRequest to SimpleSaml, WSO2 IS receive LogoutRequest from SimpleSaml but don't answer and WSO2 IS produces error:
ERROR {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Context does not exist. Probably due to invalidated cache
I think, it is due to absence of sessionDataKey parameter in the logout request from SimpleSaml.
In IDP metadata for SimpleSaml I set a SingleLogoutService as
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://<server>:9443/commonauth"/>
Maybe it is not right URL. But I don't find SingleLogout URL for our configuration.
Could somebody help to resolve this problem or it is not possible to use WSO2 IS in such configuration?
Many thanks in advance!for
P.S. I'm very sorry for my english
What I understood from your comments that you have the setup of SimpleSamlPHP as your IDP which has connected to multiple SPs.Even the SimpleSamlPHP connected to WSO2 IS too.One of the SP send the Logout request to your SimpleSAMLPHP and the SimpleSAMLPHP pass the Logout request to WSO2 IS.
Let me describe how the logout request works on SP initiated Logout request.
LogoutRequest issued by SP to IDP
IDP determines authenticated SPs for given user session. If there are no SPs, other than the SP who sends logout request, the profile proceeds with step 5. Otherwise, steps 3 and 4 are repeated for each SP
LogoutRequest issued by IDP to SP
SP issues LogoutResponse to IDP
IDP issues LogoutResponse to SP who sends logout request.
The Logout URL you can make your custom URL where you want the user to redirect.
Refer the below Url to configure the external IDP to WSO2 IDP.
http://pushpalankajaya.blogspot.com/2014/09/leveraging-federation-capabilities-of.html
If you are using /samlsso end point in WSO2IS, It means that your are using SAML2 SSO. Therefore, you must send a proper logout request to the /samlsso end point. If you need to get more idea about SSO logout with SAML2 SSO, Please go through the below URL.
http://xacmlinfo.org/2013/06/28/how-saml2-single-logout-works/
I am testing SAML SSO using WSO2 Identity Server 5.0.0 with two PHP application instances as service providers (using onelogin phpsaml). I managed to make the single sign on to work but now I'm facing a problem with single logout.
When I trigger a logout request from the PHPApp1, WSO2 IDP responds
with a logout response and it seems to works fine;
WSO2 IDP triggers a logout request to the saml session particants, in this case to the PHPApp2;
The PHPApp2 handles the logout request and redirect to the WSO2 IDP logout url with the LogoutResponse;
And now the issue: WSO2 does not seems to handle the logout response from PHPApp2 and prints in logs the following message:
WARN {org.wso2.carbon.identity.sso.saml.logout.LogoutRequestSender} - Failed single logout response from http://php-app2.dev/saml/sls with status code Moved Temporarily {org.wso2.carbon.identity.sso.saml.logout.LogoutRequestSender}
After that WSO2 keeps trying sending logout requests to the PHPApp2 and ends up with the following message:
ERROR {org.wso2.carbon.identity.sso.saml.logout.LogoutRequestSender} - Single logout failed after retrying 5 times with time interval 60000 in milli seconds. {org.wso2.carbon.identity.sso.saml.logout.LogoutRequestSender}
I tried to enable debug logs in WSO2 to obtain more detailed information about the issue but I am not able to get any helpful information.
Is there any way to get more detailed information about this issue?
Any help is welcomed.
Michael, In the SAML Single Logout implementation, when the PHPApp1 initiates the logout, it redirects the user to WSO2 IDP. Then WSO2 IDP validates the LogoutRequest message, after successful validation, WSO2 IDP figure-out the existing session participants (in this case WSO2 IDP will detect PHPApp2). So after session participants are figured, the WSO2 IDP will send Logout Requests to those in stateless way (no browser involvement) and the session participants (PHPApp2) should validate the Logout Requests from the WSO2 IDP and should send the Logout Response back (no browser involvement, no redirections) to the WSO2 IDP. After WSO2 IDP receives all the LogoutResponses back from the all session participants, WSO2 IDP contract it's Logout Response to the initiator which is PHPApp1, this will be sent as a browser redirection (HTTP Form submission).
Well, the problem is due to the fact that onelogin/php-saml implementation handles the IDP Logout request by redirecting the response to the IDP.
I change the code to returns the response instead and it is working now. Considering that I am new to the SAML standards, I am not sure if it is the correct way to solve that.
WSO2 IS works with strong assumptions that servers could see and talk to each other. This way it tries to be polite and sends the logout requests on back channel (server-to-server without user involvement). As the response the SP should send back a valid logout response. The WSO2 IS currently checks only the HTTP status code (200).
SimpleSAMLphp works with user browsers (and assuming the requests are coming from the user) and after receiving the logout request it tries to redirect the user back to IDP with the SAML Response using Redirect-binding. It's issuing HTTP 302 response.
Try to configure the SimpleSAMLphp to use POST binding for logout (in saml20-idp-remote.php). Still - SimpleSAMLphp it may try to redirect the user before returning the form with logout response and WSO2 IS will not follow the redirects.
Gabriel
Make sure you are using a database type session store.
SimpleSAMLphp can then kill the session without the browser context when it receives the LogoutRequest from the remote server directly rather than through a browser redirect.