I am using latest version of Spring Security SAML to simulate an RP.
I need to view the SAML Logout Request and Response on the logout.jsp page.
It is easy to view auth request and response on a JSP page, but I am not sure how that works with the logout process.
Thank you
You need to install addon SAML tracer for firefox. https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/
Related
I've a Gatsby (React) page with a contact-form which sends the params to an API endpoint.
The form is on the browsers client side.
That Api Endpoint sends to an Email service provider, so far so good.
BUT how can I prevent people from sending emails directly to that endpoint /api/contact-form, in my contact-form I have a ReCaptcha to do that, but the API endpoint is not "secured".
First I thought I can do that with a "host"-check... but the page is on the client side...
Is it the right approach to create a token, when the page is delivered to the client, and check it then against on the API endpoint?
I assume you're talking about CSRF token. It is definitely one way to prevent CSRF attacks. The other option could be setting cors to allow only specific origins to access your API endpoints.
Chrome plans to implement the new secure-by-default model for cookies with Chrome 80 in February 2020.
Now I am testing all our applications that might be affected.
For authentication/authorization we use oidc-client (on UI) and IndentityServer on backend.
The workflow is the following:
request:
POST http://my_identity_server/api/authenticate
{userName, password}
response:
Set-Cookie: idsrv=abc
{"redirectUrl":"http://my_identity_server/connect/authorize/callback?client_id=MyApplication&response_type=id_token token&scope=openid"}
request
http://my_identity_server/connect/authorize/callback?client_id=MyApplication&response_type=id_token token&scope=openid"
Cookie: idsrv=abc
response:
302 Location: http://myApplication/#id_token=123&access_token=456&token_type=Bearer
request
http://myApplication/#id_token=123&access_token=456&token_type=Bearer
When application is loaded, Oidc-client adds IFrame to do silentRenew that actually sends additional requests
GET http://my_identity_server/connect/authorize?client_id=MyApplication&response_type=id_token token&prompt=none
Cookie: idsrv=abc
What I don't understand why this last requests indide IFrame include idsrv cookie? The request is done inside an IFrame and it's definitely a third-party cookie.
If I switch SameSite setting to "Strict" everything works as expected, cookies are not send.
If someone can explain me the case or suggest some ideas to check, would be nice! thank you!
OIDC client library uses OIDC session management to track of the session which is done by using OP iframe and client(RP) iframe.
Identity server issues idsrv:session cookie for this purpose
check this
https://medium.com/#piraveenaparalogarajah/openid-connect-session-management-dc6a65040cc
I have setup an Application that's is using OKTA as IDP. The app is SAML Based.This part is working fine.
But I am unable to log out. For this we have
1. Enabled Single Logout
2. Set the Single Log out URL (I received this from Metadata of IDP under header Identity Provider Single Logout URL)
3.Sp Issues (I received this from Metadata of IDP under header Identity Provider Issuer )
4. Signature Certificate (This is the certificate of IDP)
Now when I call the Logout URL I am receiving 403. On checking the Logs of OKTA I see the (User Single Sign out from App Failure:- Malformed Request)
Can any one please help me how to fix it.
I am assuming that I just need to call the logout URL and the session will kill off. Is my understanding correct?
Reviving a very old thread, check that you have a ?ReturnTo=<path> at the end of the logout URL.
Okta requires strictly post binding requests for logout. Please make sure you are making POST requests for logout and you are using correct entity Id in request.
I think the setting values below need to be set for sp side.
Set the Single Log out URL
Sp Issues
Signature Certificate
It is not on idp side.
We have a successful implementation of SSO with Okta as the IdP and an external PHP site as a SP. We are currently utilizing the Okta Sign On Widget which sends our PHP SP a SAML2 Token.
Question is, can we now change from the widget to the API and still get the SAML 2 token on successful login via the API?
So, Since posting this I figured out that - 'yes you can'. I don't know if this is the cleanest/best way but it works and here is how to do it in case anyone else gets stuck looking into this issue...
Already having SAML2 communication working between Okta as IdP and
PHP site as SP.
Create an API access token in Okta.
Use the access token to post a request for a one-time use token from
the API for a specific user you want to login as:
http://developer.okta.com/docs/api/resources/sessions.html
Redirect the user with the retrieved one-time session token to your
App's embed link with the one-time session token:
http://developer.okta.com/docs/examples/session_cookie.html#retrieving-a-session-cookie-by-visiting-an-application-embed-link
This will log the user into Okta to get a proper session we can then
use to send to our PHP end-point to get the SAML2 token we want but
while utilizing the full customization benefits of the API.
The SAML Response will be posted to the following url:
https://domain/sp/ACS.SAML2
But when I try to hit the url, I am not able to see the response.
Anything wrong in my approach?
Thanks & Regards,
Aswini J
A few things assuming you are setting up SAML 2.0 Web SSO Profile -
What do you mean you can't "see" the Response? Are you successfully logging into the IDP and having it redirect the Browser to the PF ACS URL?
With PingFederate, the application and protocol end-points are case sensitive. You should use http(s)://www.server.com:<PF runtime port>/sp/ACS.saml2. If you simply request this value from your browser with a GET request and no SAML data, PingFed will show you a generic error template page.
If you have successfully POST'd the SAMLResponse to the right endpoint, you will see the actual SAMLResponse logged in the /pingfederate/log/server.log.