I have set up SLO with sustainsys-saml2 for a MVC-project and it seems to work but the problem is that we get returned to the entrypoint after logout. In my dev-environment I am using the stubidp from sustainsys and I will get the startscreen for stubidp directly after logout and that is ok but in a testenvironment with ADFS as idp it will automatically log in again.
I have tested to logout by adding /AuthServices/Logout?ReturnUrl=/status (status-page does not require login) and it seems to work since I will land on the statuspage. If I instead would set http://www.google.se as ReturnUrl it does not work. So my question is if it is possible to configure what is sent in to ReturnUrl for logout in WebConfig and does it always have to be relative to my applications url?
Kind Regards
Eric
Only local URLs are allowed by default, to stop open redirect attacks.
If you want to allow a specific remote URL, you can implement the ValidateAbsoluteReturnUrl notification to return true for URLs in a whitelist. Don't "fix it" by simply returning true for anything - that will lead to an open redirect vulnerability.
Related
TLDR: I have a site protected with Okta SAML authentication, but somehow during my redirect and authentication phase, the redirect, which is a parameter in the URL, gets lost. Looking for advice.
Background:
I have a Linux server with Apache using Mellon to connect to Okta for SAML authentication.
I have a url like this:
https://docs.example.com/current/readme
I have a redirect.php file at the root of example.com that redirects the user to something like
https://docs.example.com/docs/version/Default.php#cshid=readme
That is the generated output URL for context-sensitive help, which in turn redirects the user to something like:
https://docs.example.com/docs/version/content/readme.php
That all works if you are already authenticated with SAML. However, if you aren't already authenticated, you get sent to Okta.
https://success.example.com/login/login.htm?fromURI=%2Fapp%2Fssoexample_docsexamplecom_2%2Fexk4g2c3ofeuJWRSu4x6%2Fsso%2Fsaml%3FSAMLRequest%3DhZJfT8IwFMW%252FytJ3aBljaAMkAyTBqDHgn8QX0pSLNG7t7G0Rv73tFhVf8KnN7Tm553fSEYqqrHnh3V6v4N0DuulSA3Em%252BLmymiTL%252BZhsslk6HE6nxbTH8sHVIOvnLGWzxXSYXxbZBVuQ5pYanRCuzBiaa%252FD8k46eOgNOevxjL2QZB4YlBauce2dq5FTil5KQOweQIud6kpTUW2TUji%252BZa%252Bp7Jsd%252BOvkycxohJjhHK1sRVx6a8PZUVVdKqkcSRbGSmhKH5OdKBEi2n1oRx3gZ1J8lxWX%252BQrsGuxBSXhc3fyCxdynVBWUpdG0NuhWgHVMQCajGJo35dnJeeeInmpH7fe4C2jL%252Bb0J6T9j9kr8Qx4natvZNVLurNCoQgOBKez4mFkQLnA664HQSbvy7yecfAE%253D%26RelayState%3Dhttps%253A%252F%252Fdocs.example.com%252FDocs%252Fcurrent%252FTopNav%252FDefault.php#cshid=readme
So, at the end of that URL, the hash and parameter are retained: #cshid=readme
However, after I successfully log in, somehow the URL looses the #cshid=readme and just redirects me to:
https://docs.example.com/docs/version/Default.php
Any ideas how I can make it retain the hash and the content after the hash? I'm not the person who configured mellon or Okta, but I'd like to have a solution in mind before I contact them with my issue.
In case someone else comes across a similar issue, there are a couple of possible solutions to these scenarios.
Replacing the # with ?. In this context, https://docs.example.com/docs/version/Default.php?cshid=readme
Encoding the # as %23 (still not likely to work in most cases). https://docs.example.com/docs/version/Default.php%23cshid=readme
It is expected that everything after the # is dropped. Fragment parameters are used only on the client-side, but the server will ignore it, which is why Okta is ignoring that portion of the URL.
Using ? instead of # will usually solve most issues.
I am attempting to Login to my app with JMeter Script.
I have Cookie Manager and a Cache Manager added
My Thread Group script
GET on main login page (/app) to return session id and form fields
and cookie
POST of completed form fields with cookie (/posthandler) with "follow redirects
What happens is
POST sends initial cookie (from GET) and form fields and logs in ok
the session is established (I see a record in our app database)
the response is a redirect with a new cookie
JMeter redirects (GET) to the session url (/app?session=xxxxx)
this goes with "[no cookies]" (according to request panel)
As that request arrives without the new cookies - the app issues a second redirect back to the login page.
So is there a way to force the GET Redirect after the POST response to send the cookie?
My theory is that JMeter is that, because of the different URI path for the POST and redirect GET, JMeter is not sending the cookie.
I have tried
various Cookie Manager settings (standard, default, compatibility).
followed this Understanding and Using JMeter Cookie Manager and set check.cookies=false.
and advice SO - JMeter: Login flow involving URL redirection not working including making sure there was an init
My problem was self-inflicted !
I was running against a different environment than usual which had a different context root e.g. /test/app rather than /app. For this I amended my ${Domain} User parameter with "my.domain.com/test" rather than adjust all the Path settings.
For requests sent this approach appeared to work as the ${Domain}+${Path} resolved to the correct URL - but the Cookies created by the server were for ${Path} (as in /test/app) and JMeter was seeing this differently (as in /app).
I have now introduced a ${CtxRoot} User variable (set to /test/) and prepended this to all my Path values - and my Login is now working.
Looking through some legacy code I have in front of me using struts one, I see:
<global-forwards>
...
<forward name="accessDenied" path="/www/jsp/AccessDeniedForm.do" redirect="true" />
</global-forwards>
So it's just a global forward to send to a access denied page.
I am curious about the decision to redirect as opposed to forward. What are the advantages and disadvantages of using it?
What are the pro's and con's of using it?
Before discussing pro's and con's of using that forward element with redirect set to true, let's understand what is actually going on with that configuration. When redirect is set to true in the forward element, a redirect instruction should be issued to the user-agent so that a new request is issued for this forward's resource. This link will probably provide detail information that you need.
The default value for redirect is to false, essentially when the forward element is called, it forward to that path specified and that's it. If you are setting redirect to true, take for example, the browser will make another request. So I think with these said, you probably know or have an idea the pro and con if you really want to use it.
In redirect, the control can be directed to different servers or even another domain name.The redirect takes a round trip.When a redirect is issued , it is sent back to the client , and redirected URL information is in the header instructing the browser to move to the next URL. This will act as a new request and all the request and response data is lost.
In forward , the forwarding is done from server side , the client browser URL do not change.the data is also not lost.It is just like a browser page refresh. Whatever data posted in the first submit is resubmitted again.So use it with caution.
Both forward and redirect are used in different scenarios ,the global forward should be redirect because it is an error situation.
Redirect is slower as it needs a roundtrip.Forwards are faster.
If you specify
redirect="true", Struts uses a client-side redirect
[response.sendRedirect()]
. The JSP will be invoked by a new browser request, and any data stored in the old request will be lost.
I'm trying to pass some variables to my facebook app from the url, i.e. using GET variable app_data like facebook wants.
At some point I've stopped getting the ['signed_request'] part of the $_REQUEST. When I print_r($_REQUEST) I'm getting: ['doc'], ['user'], ['__utmz'], ['__utma'] and ['session'] values, but not signed request :(
Any ideas of why this might be happening?
Check the tab/canvas url is EXACTLY the same as required. If there is a redirect to another page, then signed request and other values will not be sent. You can check using a browser sniffer, if a call to the page responds with a 300 (301/302 etc) redirect, then you need to change to what it redirects to.
Examples:
https://example.com/ may need to be https://www.example.com/ (add www., or remove www. depending on how server is set up)
www.example.com/ may need to be www.example.com/index.php (add index.php, or the right page).
Check you are using http:// and https:// correctly in the URLs, and that https:// returns a valid page.
I've only been able to get the signed request in https://, i get no request at all in http.
Currently have a bug on FB, but no word on fixing it yet; http://developers.facebook.com/bugs/264505123580318?browse=search_4eb3ef23eb18d6649415729
EDIT:
http://SITE.com was redirecting to http://www.SITE.com, so I was loosing the request variables.
Had a similar issue, for me it was as simple as a mismatch of the app id and app secret! However in facebook developers backend I have noticed that the URLs all need to have that trailing slash!
Some browsers do redirect your request to https automatically if you have been on this particular site on https so if you are in http mode on facebook there is situation:
facebook requests http version of your app, browser redirect this request of facebook to https and POST data and thus signer_request are gone in this process...
i see this problem in chrome 23, if you delete browsin data (particulary Deauthorize content licenses) app should run back on http
Is there a way to go to a url without redirecting to it? Basically I want to call a url from within my application in the background so it can logout a reliant party.
Appreciate the help.
What you are trying to do does not compete us to answer as it's directly related to your own Authentication implementation.
A normal ASP.NET Authentication based in Forms Authentication you will need always to lunch the url from a browser as it is there that relies the Authentication given.
You can give yourself a try by opening your website and log in into it, after that, open other browser brand (not browser window) into your application url... you will see that you also need to login again as the Authentication is hook up into the first browser.
It's Up to you as Application Architect to make this by implementing another way of authentication, normally in this kind'a cases, this happend when consuming web services where you need a authentication code first (given by calling a Login method) and that code is always needed to be appended to the body or header of any call to the system.
This way you can easily remove the authentication code and all procedure calls will fail.
As said, this is not up to us, it's up to you to create the correct Authentication Layer.
from your comment
it's as simple as using WebClient object
WebClient client = new WebClient ();
string reply = client.DownloadString (address);
If you wish to transfer to a new url request you can still use
Server.TransferRequest()
The problem with this is that by not using a redirect the browsers address bar will not reflect the fact that you have moved their request to another URL.
To have the client visit a given URL in the background you should either make an AJAX call to it or possibly have an image with an src of your logout url (though you'd have to make sure that you return a FileResult of your image too). This is how most analytics packages call to their relevant urls in the background.
The problem here though is that neither is 100% reliable, turn off javascript or images on your browser and these results fail.
From what you've said I think what you're after is for a user to continue to any of a variety of pages rather than a specific logout page. If this is indeed the case your best solution is in fact a double redirect.
Have your application redirect to your logout url but before hand put the url of the page you want them to go to into tempdata. Then in the actionresult for the logout page you can do your logging out as required and return a redirect to the url from tempdata.