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.
Related
I'd like to use Keycloak to have SSO between my websites and a chrome extension. I've already set up two websites that share the same session and only require the user to login once.
However, when I'm trying to add authentication to my extension using chrome.identity.launchWebAuthFlow(), it does not seem to check cookies for SSO and systematically prompts the user to login, even though I'm already logged in my other sites.
I've tried to do things "by hand" using chrome.windows.create(), and it does skip login credentials to redirect me directly if I'm already logged in from another site, so SSO seems to be working that way. Unfortunately I don't know how to catch the redirection event that occurs once login is complete and then go back to my extension, so I'm stuck on this lead as well.
Do you know if it's possible for the chrome.identity.launchWebFlow() method to check cookies and only prompt for login credentials when it detects no session cookies ?
We are currently having problem allowing a user to a specific URL without logging in in Azure AD authentication.
We are successful in getting token and using it for our API's. But we are currently having problem allowing user to access a URL without them logging in.
What we have tried so far was this links
https://learn.microsoft.com/en-us/graph/auth-v2-service
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Thanks!
In your second link, in the azure portal-> your app service -> authentication and authorization screen, make sure the "action to take when request is not authenticated" is set to allow anonymous. if you set that option to "log in with active directory" that forces authentication on every page no matter what. And ensure in your code that page doesn't require login eg.remove the [authorize] tag.
We are currently implementing keycloak and we are facing an issue that we are not sure what’s the best way to solve it.
We have different webapps making use of the sso and that’s working fine. The problem we have is when we make log in using the sso in one webapp and then we do the same in a different webapp.
Initially this second webapp does not know which user is coming (and it’s not necessary to be logged in to make use of it). When clicking on “login”, it automatically logs in the user (by making a redirection to keycloak and automatically logging the already logged user in the other webapp). This second logging happens “transparently” to the user, since the redirection to keycloak is very fast and it’s not noticeable. This behaviour is not very user friendly.
The question is: Taking into account that this second webapp can’t know upfront which user is accessing the site (unless actively redirecting to keycloak), is it possible to force always the users to log in for a specific keycloak client? By this I mean actually ask the visitor for user/pw even if keycloak knows already them from other keycloak clients.
Thanks in advance!
In the mail listing from keycloak, they gave me a good solution but for version 4:
in admin console, go to Authentication
make a copy of Browser flow
in this new flow, disable or delete Cookie
go to Clients -> (your client) -> Authentication Flow Overrides, change Browser Flow to your new flow, click Save."
Use logout endpoint as a default login button action in your app and redirect uri param use for login page, where you use your specific client (of course you need proper URI encoding):
https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/logout?redirect_uri=https://auth-server/auth/realms/{realm-name}/protocol/openid-connect/auth?client_id=client_id&redirect_uri=.....&other_params....
=> user will be logged out and then it will be redirected to the login page
We have a project that uses IdentityServer4
https://github.com/IdentityServer/IdentityServer4
We have 3 domains: auth, admin and www
IdentityServer runs on auth and the other two are ‘clients’.
www uses the Hybrid flow (cookies)
admin uses the Implicit flow (it is a SPA, using oidc-client)
We have a single login page hosted on auth. When the user logs in they are taken to www. Some users are allowed to access admin and they will see a link in the navigation.
After you login, when you access the admin you can see the authentication happen automatically and return to the callback URL. This all works fine.
However if I logout from the admin I can still access the www, and vice versa. Ideally we would like the logout to log the user out of both clients at once.
Is this possible?
Note: I'm the front end developer on this project, so the guy who actually implemented it may provide additional details in comments below.
Yes this is possible.
The docs for idsrv4 are not done yet - but it works pretty much like this
https://identityserver.github.io/Documentation/docsv2/advanced/signout.html
This is an implementation of the signout spec for JS
https://openid.net/specs/openid-connect-session-1_0.html
..and for web apps
https://openid.net/specs/openid-connect-frontchannel-1_0.html
you need to read those documents to understand the mechanisms
My experience with Shibboleth is limited and I have no access to configuration or logs on the IdP or the SP. I am trying to troubleshoot this issue:
Previous Shibboleth session is still active on the client workstation. When attempting to access document protected by the following .htaccess configuration:
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
The client (occasionally) receives the following error message:
Authorization Failed
Based on the information provided to this application about you, you are not authorized to access the resource at "http://myresourcepath"
Please contact the administrator of this service or application if you believe this to be an error
In troubleshooting, I changed .htaccess from
require valid-user
to:
require shib-session
I thought the issue might be the deprecated parameter- but after changing, I was still receiving the authorization failed message. The only way to successfully authorize is to clear the browser cache, revisit the page which then it prompts for authentication, and then authorization passes its check and you hit the page successfully with no error.
What complicates matters even more, is, when .htaccess is set to:
require shib-session
The authorization error message persists even after clearing the cache and re-authenticating. I had to change .htaccess back to
require valid-user
I dont know what could cause the random authorization issue, if the session wasn't valid, the user would get directed to the idp for login, correct? Thats Shibboleth's design. So, the session has to be valid- but why does it not recognize the user as authorized for that resource?
Additionally:
after I received the message and googled quickly, it seems like a stock response from the idp:
https://technical.bestgrid.org/index.php/Vladimir's_general_Shiboleth_notes
says:
This specific example asks for the user variable to be set to any value - and any Shibboleth attribute can be used with the variable name it is assigned to in the Attribute Acceptance policy (AAP.xml). For more syntax on using the require directive, see the examples in the SP htaccess documentation on specific features implemented for the Apache require directive.
Users who do not have the attribute (or do not provide it), get the following error message (with the Shibboleth logo). .... is same message....
This form of control however may not be that user friendly - user would have to know to go either use Autograph to allow the release of the attribute, or talk to their IdP administrator to configure the attributes on the IdP.
Also note that this does not work with lazy sessions - in which case one immediately gets the same error message.
Further, note that care must be taken with overlapping access control blocks. These should be listed from the most-generic ("/") to the most specific (as "/secure" in the above example). Otherwise, the more relaxed settings on the generic one would override the more stringent settings on the specific one.