We've setup federated security using ThinkTecture server.
When a user wishes to access a particular URL, they get redirected to the Identity Provider Server (IDP), they login, get authenticated.
Then, the IDP server will redirect the user back to the "Redirect URL" specified in the configuration for that Relying Party.
Instead, I want it to be redirected to the originally requested URL.
Is this possible? I've read a little about the wreply parameter, but not sure how I use this and intercept the authentication levels calls on the original web server, before the redirect.
Update
I've realised that my problem is due to my url containing a hash, e.g. http://domain.com/#customer/123 and nothing after the hash is passed into the redirect url within WIF. See my answer below for more details.
It's up to your app to remember context info like this in the wctx param. If you're using WIF in the RP then this should be done automatically.
I figured out what was happening. I am using WIF and as Brock's answer suggested it should be doing everything itself...and it was.
Normally if you request a url like: http://domain.com/page and the 'Redirect To'/ReplyTo setting in ThinkTecture is just http://domain.com/.
Then when WIF calls out to the STS, it takes the path of the requested domain, in this case /path and adds it to the &ru param within the &wctx param. The &wctx param will look like this: rm=0&id=passive&ru=%2fpage.
Then after the STS has authenticated it redirects the user back to the ReplyTo url, http://domain.com with a body parameter of wctx and WIF picks this up and uses the ru param to do another redirect.
The problem is that my requested url was http://domain.com/#page and WIF doesn't include the #page in the ru param. So my ru param was just /, so it kept redirecting to http://domain.com which there was correct (yet incorrect).
Guess I need to set the ru value myself with the full URL... unless there is a better way.
Related
I have configured an OpenID Connection application on OneLogin (not sure the provider matters) with a configured post MFA authentication redirect uri of
http://localhost:4200/LoginResponse.aspx?
The code behind my LoginResponse.aspx page grabs the returned id_token and processes it.
The issue is that after my initial redirect to the MFA login and successful login/MFA validation, the redirect is coming to
http://localhost:4200/LoginResponse.aspx#id_token=12345678987...........
Note the "#" symbol after my .aspx extension. This is corrupting the parameter string that is returned and not allowing me to grab the value of id_token from the Response.
After the redirect comes back, if I simply manually replace the "#" with a "?" and hit enter, my LoginResponse.aspx page loads fine and finds the id_token and processes it with my business logic.
My question is, how can I get the redirect to actually return to "LoginResponse.aspx?" so that I can grab the parameters.
On my OpenID Application I have tried the following options as Redirect URIs
LoginResponse
LoginResponse.aspx
LoginResponse.aspx?
LoginResponse.aspx?action=test
Did that last one to see if I could get around the ? not being there. But that just redirected the page to "LoginResponse.aspx?action=test#id_token=..............." So again, I could not grab the "id_token" variable out of the URL Response/QueryString.
I just cannot figure out how to get rid of this unwanted "#" sign and have a "?" after my .aspx extension.
Any help would be greatly appreciated!
I assume you are using the implicit flow to retrieve the tokens and in this flow you can either get back the tokens in the URL with the #. The # is added to make sure the tokens are not sent back to the server, instead they just stay in the browser. If it was a #, then the secret tokens would be sent back to the server and end up in various logs and creating various security issues.
I don't know how you implemented the client, but in OpenID Connect, if you add this parameter "&response_mode=form_post" to the initial authorization request, then you will get back the token using a POST request instead. just like this picture shows:
PS, I doubt you can get back the tokens using a ? instead of #.
I need some help in resolving a strange behavior I came across while using Thinktectures Embedded STS locally in my ASP.net MVC application. I don’t see this issue on the server using ADFS.
The issue is
After I sign in into the application, most of the HTTP calls from then on are getting called twice.
The first HTTP request goes without the FedAuth cookie to which the server responds with a status code of 302 (redirect) and another request to the same URL is made but this time with the Fedauth cookie. I'm trying to understand what is causing the browser to send the first request without the FedAuth cookie and also why the server redirects to the same URL?
I also need help in understanding how the EmbeddedSTS URL gets resolved. I went through the code on Github but it is not very clear to me how the EmbeddedSTS url is resolved.
Any help is appreciated.
I was able to figure out the issue on my own.
This issue is related to cookie paths being case sensitive. My virtual directory in localhost was configured as ATSWeb but while making AJAX calls I am constructing the full URL with a different case for the virtual directory (atsweb).
Since the ADFS cookie was set with the path /ATSWeb, while doing the AJAX call the browser is not sending the Fedauth cookie to the server. This is leading to all sorts of issues.
You can read more about cookie paths at the links below.
http://www.allbacktomine.com/blog/2009/02/04/BrowserCookiesThePathIsCaseSensitive.aspx
Why are cookie paths case sensitive?
I'm currently using a Preauthentication with Spring Security through an SSO solution, and was having a problem with #'s in the URL. I noticed if you URL encode the #, the redirect would work correctly if the user was not logged in, so I wrote a filter that would look for URL encoded parameters, and decode them. The problem is, now if you are logged in, it seems like the URL is being decoded, and my filter is never being touched.
This is a really confusing question, but I'll try to explain what I am seeing through how the requests are handled.
Not Logged In:
/%23/some/resource
Redirect to SSO:
SSO Redirects to:
/#/some/resource
This works well.
Logged In:
/%23/some/resource
:
/#/some/resource is the URI passed, so no rewrite needed, verified through debug logging that the URL is being passed through.
/%23/some/resource is returned to browser, 404 is returned.
Where I am getting confused is why it's decoding, then it seems to be re-encoding the URL after the filter-chain (maybe?)
Thanks for any help!
I Recently set an aspnet application under win 7 IIS 7 and got enabled SSL for this app.
the app works great under ssl, but when i change the schema from https to http, using a response.redirect, the request get a timeout, i am stuck with it, any idea is welcome.
regards
You cannot switch protocols unless you provide an absolute URL. The reference must be absolute.
make use of the encryptedUri and unencryptedUri attributes. "unencryptedUri" may be specified to send the user back to another domain or specific URI when the module removes security.
You can have a custom configuration..
<secureWebPages
mode="RemoteOnly"
encryptedUri="secure.mysite.com"
unencryptedUri="www.mysite.com"
maintainPath="True"
warningBypassMode="AlwaysBypass">
...
</secureWebPages>
An example would be to redirect secure requests to secure.mysite.com and requests that don't need to be secure could be redirected back to www.mysite.com. maintainPath is used in conjunction with the above attributes. When the module redirects to the encryptedUri or unencryptedUri, it appends the current path before sending users on their way.
I implemented OpenID support for an ASP.Net 2.0 web application and everything seems to be working fine on my local machine.
I am using DotNetOpenId library. Before I redirect to the third party website I store the orginal OpenID in the session to use when the user is authenticated (standard practice I believe).
However I have a habit of not typing www when entering a URL into the address bar. When I was testing the login on the live server I was getting problems where the session was cleared. My return url was hard coded as www.mysite.com.
Is it possible that switching from mysite.com to www.mysite.com caused the session to switch?
Another issue is that www.mysite.com is not under the realm of mysite.com.
What is the standard solution to these problems. Should the website automatically redirect to www.mysite.com? I could just make my link to the log in page an absolute url with containing www? Or are these just hiding another problem?
Solve the realm problem that you mentioned is easy. Just set the realm to *.mysite.com instead of just mysite.com. If you're using one of the ASP.NET controls included in the library, you just set a property on the control to set the realm. If you're doing it programmatically, you set the property on the IAuthenticationRequest object before calling RedirectToProvider().
As far as the session/cookie problem goes with hopping between the www and non-www host name, you have two options:
Rather than storing the original identifier in the session, which is a bad idea anyway for a few reasons, use the IAuthenticationRequest.AddCallbackArguments(name, value) method to store the user's entered data and then use IAuthenticationResponse.GetCallbackArgument(name) to recall the data when the user has authenticated.
Forget it. There's a reason the dotnetopenid library doesn't automatically store this information for you. Directed identity is just one scenario: If the user types 'yahoo.com', you probably don't want to say to them 'Welcome, yahoo.com!' but rather 'Welcome, id.yahoo.com/andrewarnott'! The only way you're going to get the right behavior consistently is to use the IAuthenticationResponse.FriendlyIdentifierForDisplay property to decide what to display to the user as his logged in identifier. It gives more accurate information, and is easier than storing a value in the callback and getting it back. :)
I dunno how OpenID works, but LiveID gives you a token based on the combination of user and domain. I just would have forwarded www to mysite.com.
The cookies and sessions and everything else get lost between www.site.com and site.com. I don't have patience enough to thoroughly read all the specs, but http://www.w3.org/Protocols/rfc2109/rfc2109 states that
A is a FQDN string and has the form
NB, where N is a non-empty name
string, B has the form .B', and B' is
a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)
Note that domain-match is not a
commutative operation: a.b.c.com
domain-matches .c.com, but not the
reverse.
I think that means yes, you do need to forward to www. I have always added domain correction code to my sites when cookies and sessions are being used.