I'm trying to use WsFederation on a "SSO Site" to authorize across a family of apps on the same domain. In my test configuration, I have the following setup:
SSO Site
example.com/SSOSite
Wtrealm is https://example.com/SSOSite
Wreply is https://example.com/SSOSite/signin-wsfed
Sample App
example.com/SampleApp
Wtrealm is https://example.com/SSOSite
Wreply is https://example.com/SSOSite/signin-wsfed?appName=SampleApp
Expected Result
An unauthenticated user navigates to example.com/SampleApp
The user is redirected into the Microsoft SSO login flow for example.com/SSOSite
Login process completes, sends user to example.com/SSOSite/signin-wsfed?appName=SampleApp
SSO Site application handles redirect back to Sample App site
Actual Result
In step 3 above, /signin-wsfed responds with a 302 pointing at / - that is, the root of example.com.
If I go directly to example.com/SSOSite, it completes the login as expected and /signin-wsfed passes control along to my own login controller method. It's only when the request begins at /SampleApp that signin-wsfed responds with the 302 to /
My Question
Why does this 302 to / happen? Is there a way to accomplish what I'm aiming for - using one realm to handle all logins and then send the user back to their desired application when the login completes?
Related
I have a pretty straightforward ASP .NET Core web site that uses Azure AD + OpenID for user authentication. Inside Azure I've added "https://my-site/signin-oidc" as a Redirect URI and inside my app settings I've set my CallbackPath to "/signin-oidc".
The problem is after authentication the browser always redirects to the home page.
For example the user will enter the following url into their address bar:
https://my-site/#/foo
They'll then be redirected to the azure sign-in page which has a uri like so:
https://login.microsoftonline.com/.../oauth2/v2.0/authorize?client_id=...&redirect_uri=https%3A%2F%2Fmy-site%3A64199%2Fsignin-oidc&[...]&sso_reload=true#/foo=
(Note where the '#/foo' fragment is placed)
After authentication succeeds they end up at the home page (https://my-site/).
Is there anyway for me to preserve the original URI and redirect the user to it after auth succeeds?
Try using the post_login_redirect_url query parameter for this.
If you want to automatically navigate the user to #/foo' after logging in, you can set your login redirect to ~/.../authorize?post_login_redirect_url=/#/foo.
I need to test a web-application using JMeter.
Every time I give the path, it gets redirected to auth0 to login
Is there a way I can save the credentials, so that every path I mention is accessed with those credentials and doesn't always redirect to login?
Most probably no. Consider each JMeter thread (virtual user) a normal user using a real browser.
If you open a new browser window in "porno mode" and try to give an URL which requires authentication - you will be redirected to the login page.
However if you're logged in already - you should be able to open any page without providing credentials.
In the absolute majority of web applications it's being implemented via Cookies so given you add HTTP Cookie Manager to your Test Plan - you should be able to navigate through your application (given the first N HTTP Request samplers which are responsible for login are successful)
Focussing on the authorization_code grant type (server to server) I am confused as to how a client (in this case a web server app) matches a response (positive) to the outgoing request.
The response is a redirect with code in the URL (not interested in the token part yet). How does the web server know who this code belongs to?
After working with OAuth now for a couple of weeks I understand now how this works.
If we are talking about granting application A logged in user U authorisation to access resource R.
The user U starts off in application A and is logged in there in the browser which means in most cases that a cookie is set with a session token.
The user U is redirected to application / resource R where he would login (or be automatically logged in using a resource R session cookie).
Presuming he grants the request he is then redirected in the browser back to application A with a code C.
Here again the seesion cookie for application A from step 1 is presented to the server but along with the code C. The server of application A can then use this code to get a token for the user U.
Note: Similar questions deal with either Auth0 with Angular or are several years out of date and refer to previous versions.
We're using Auth0 to provide authentication for a group of applications run on Apache with mod_auth_openidc.
The only customization is that mod_auth_openidc is configured to check whether a user has access to a specific application or not via:
<location /app1/>
AuthType openid-connect
Require claim valid_app1:true
</Location>
<location /app2/>
AuthType openid-connect
Require claim valid_app2:true
</Location>
User metadata defined in the Auth0 settings (valid_app1 or valid_app2, etc) defines whether a user can access the applications located at website.com/app1 or website.com/app2, etc.
Currently, the user is correctly redirected to the Auth0 login page when the user tries to access any of the applications, and correctly rejects those users who do not have access to that application.
However on a successful login, the user is redirected to the callback page (defined as the first callback in the Auth0 settings and the OIDCRedirectURI in auth_openidc.conf, e.g. website.com/auth) and not back to the application the user attempted to load.
How do I configure Auth0 with Apache so that a user is returned to the URL of the application they initially attempted to load and not the callback URL?
Good
website.com/app1 > AUTH0 login > website.com/app1
website.com/app2 > AUTH0 login > website.com/app2
Bad
website.com/app1 > AUTH0 login > website.com/auth
You can accomplish this with a few different approaches:
You can register more than one callback/redirect URL within the client application configuration in Auth0 and then each application starts the login process by telling Auth0 the redirect URL associated with it.
You can represent your applications as multiple client applications in Auth0 where each one has a specific callback redirect URL and each application starts the process with that redirect URL.
You can continue to use the same callback URL and then do a second redirect to the final destination. This implies knowing where the user started the process which can be achieved by leveraging OAuth state parameter (this parameter should also be used for CSRF protection, see Using the State Parameter.
Options 1. and 2. are very similar, usually if we talking about conceptually different applications you would go with option 2 and if it's a single application that just wants to have two different ways of processing the callback you would go with option 1..
Finally, option 3 allows a similar thing to what's done in the first option, that is, the same application can conditionally redirect users to different places after login, but does it without the need to register additional redirect URL's in the Auth0 side. It's the application itself that decides where the user goes after processing the login at the callback URL.
When i try get access token via oauth (oauth screen with Allow button) on my local machine it works, but when i do the same on test server: i get oauth screen, i press allow and it's redirects to callback uri with code, and then app asking for token (i use PHP lib):
$client->authenticate($request->get('code'));
$access_token = $client->getAccessToken());
and i get null in response and application does not get authorized and it's not in authorized apps in google account.
I've checked redirect URLs listed in Google APIs - everything matches!
And i don't get any errors from google, it's just redirects to callback url and not adds application to authorized apps list.
But it works on local with same credentials. Any one can help me and guide where the problem can be?
Solved. I did not set redirect url before $client->authenticate($request->get('code'));