Is it possible in mod_auth_openidc to do the equivalent of a
prompt=none attempt to access a protected website using credentials from an already logged in user but falling back to allowing unauthenticated access if not?
I run a website which is accessible to the public without any authentication, but also provides additional optional features for those logged in. I'd like to use mod_auth_openidc to allow users to login, but if I protect my pages with the module, it forces login before accessing the page ( as you'd expect ) and if I don't protect my pages then I can't see the OIDC variables even if I was already logged in.
So you'd go to the website and see the home page. On that page is a login button. When you log in, you are still on the home page, but now you see extra stuff (like a personalised welcome message ).
The only solution I have so far is to make my entire site available at two different urls, one protected by openidc, and one not. When you login you are redirected to the other site. But this potentially confuses users and indeed server side software which expects a baseURL to be configured.
I can implement this easily enough in other ways, but I can't find a solution based on the mod_auth_openidc module.
I tried this:
<Location /example/public>
AuthType openid-connect
</Location>
<Location /example/protected/>
AuthType openid-connect
Require valid-user
</Location>
What I was hoping would happen was that going to /example/protected would require me to login ( which it does ), and that then going back to /example/public would still know I was logged in. But although /example/protected works just fine ( so my basic setup is correct ), /example/public doesn't work at all - there are no variables set, so I still appear not logged-in.
Is there perhaps a Require option which would do what I want, or some other clean answer?
You need to use OIDCUnAuthAction pass, see: https://github.com/zmartzone/mod_auth_openidc/commit/6890b13c481f12debbd7c65a79e9dc5197deb794
# Defines the action to be taken when an unauthenticated request is made.
# "auth" means that the user is redirected to the OpenID Connect Provider or Discovery page.
# "401" means that HTTP 401 Unauthorized is returned.
# "410" means that HTTP 410 Gone is returned
# "pass" means that an unauthenticated request will pass but claims will still be passed when a user happens to be authenticated already
# Useful in Location/Directory/Proxy path contexts that serve AJAX/Javascript calls and for "anonymous access"
# When not defined the default "auth" is used.
#OIDCUnAuthAction [auth|pass|401|410]
Related
The authentication process for O365 requires adding the redirect URL in a whitelist on the app’s dashboard on Azure.
However, this whitelist doesn't work with domain names. It requires to add the entire URL for every page which is not possible if you have a huge number of URLs, plus some of the URLs are dynamically generated by the backend.
Is it possible to whitelist the domain with all its sub-directories/URLs in one go?
No, it is not (unless you want to use wildcards, which you shouldn't).
In general when you need dynamic redirects,
you should store the location you want to redirect to locally in a cookie/session/local storage/session storage.
Then use a single redirect URL, and when you get the redirect there, get that stored "local redirect URL" from where you stored it, and redirect the user there.
I touched upon this on a recent article: https://joonasw.net/view/avoiding-wildcard-reply-urls-with-msal-js
OKTA-Shibboleth(Apache)-Nakisa(Tomcat)
SSO is working for logging-in.
Now, I need to configure Logout. So, user logs out from the app, user needs to be redirected to OKTA page with tiles.
But, currently,user is redirected to the app again.
It's sending user to /logout?redirect=default.html but that default.html is captured by Apache rule and logging user back in.
It looks like it needs to hit
https://xxxx/Shibboleth.sso/Logout. When I access this url, it says logout is successfully done although it's not going back to OKTA. Does that mean that in the App's logout setting, they need to redirect to this?
But, how do I make user to go back to IdP(i.e OKTA) again?
This is what I assume that will happen.
Logout button click > logout from Shibboleth > return to OKTA so user can click other tiles.
Something to configure Shibboleth2.xml?
Document says i just need to configure the following which is there by default.
<!-- SAML and local-only logout. -->
<Logout>SAML2 Local</Logout>
But, how does it redirect user to OKTA(IdP) once user log out completes.
Is it configured in IdP's metadata ?
You can redirect the user after a local logout event anywhere you'd like, via passing the ?return= parameter a URL-encoded destination, i.e. you should update your logout link to:
https://xxxx/Shibboleth.sso/Logout?return=https%3A%2F%2Fgoogle.com
in order to redirect folks to Google once logout has taken place.
Now, you only need an Okta URL to return folks to... so I think if your client's Okta tenant is "foobar.okta.com", redirecting them after local logout to the Okta login page shouldn't prompt them to login, since they will already have the Okta Session... so maybe try:
https://xxxx/Shibboleth.sso/Logout?return=https%3A%2F%2Ffoobar.okta.com%2Flogin
Of course, you'll need to test that... but it should work, and on the off chance that the user's Shibboleth SP session was active, and their Okta session invalidated through some other mechanism, that'll just return them to their regular Okta login page.
You can obviously redirect them to any endpoint with the return parameter, for example, whatever Okta's logout URL (if you wanted to kill their Okta session too).
The only logout that's configurable by Metadata is SLO (single logout), i.e. if you wanted it to, Shibboleth can redirect the user to Okta after they complete the logout of the SP session, along with a specially-craft <LogoutRequest> assertion payload, which Okta would parse and act on in any number of ways, i.e. killing the user's Okta session, propagating Okta-initiated subsequent <LogoutRequest> assertions to other Service Providers, etc. In practice, this never really works, because such configurations are very difficult to get working between all of the relevant parties.
I have a flask app which serves an Angular JS app only to authenticated users.
Access control for the view which serves the app is implemented with #login_required from the Flask-Login package as follows:
# The app page is accessible only to authenticated users
#viewer_blueprint.route('/')
#login_required # Limits access to authenticated users
def serve_app():
return send_from_directory(
app.static_folder + '/app', "index.html")
However, I have noticed that after logging out, an unauthenticated user attempting to view this view does not get redirected to the login page, rather, they see a cached version of the app.
I have observed this behavior on Google Chrome and Firefox running the dev server.
How do I force no-caching only in the case of unauthenticated users? (I still might want caching for logged in users.)(Related questions / answers on stackoverflow seem to only address disabling caching period independent of authentication status, which strikes me as an unnecessary compromise.)
Examining the XHR log in Firebug seems to indicate the browser never even makes the original request to the protected app view. It just loads directly from cache.
EDIT 1:
One possibility would be to check authentication in the front-end app and force the redirect to the sign-in page if not authenticated, however I am interested in a back-end solution which can handle this 'automagically' so as to avoid the extra care needed on the front-end (after all, isn't this what #login_required, morally speaking, should / does claim to do?).
I have an application built in symfony 2.3 and FOSUserBundle for authenticating its users.
This application serves multiple users based on urls, pages looks like this /urlidentifier/login. This urlidentifier is a variable and it look for a [0-9A-Za-z] + to fill that slot.
FOSUserBundle config params like Login check path and logout path are saved and cached to a file (Symfony frozen parameter).For a single website user are easily authenticated with prefixing the FOSUserBundle parameters as well as Routing.
The real issue occur when the user are switch through multiple url (super privileges)
Scenario
When a super admin is logged and authenticated via urlidentifier1/login. He could switch himself to another website without logging out. Now the url changes from urlidentifier1/index to urlidentifier2/index, he would be logged in, But when he tries to logout, The parameters like logout path would be urlidentifier1/logout. When logout is triggered we will get an error like
"You must configure the logout path to be handled by the firewall using form_login in your security firewall configuration...”
How can I make the backend use such dynamic URLs?
I have a GAE app, with a URL I restrict to admin:
- url: /admin
script: _go_app
login: admin
I want to PUT or POST to this url with another Go program. What code do I need to write for the client to authenticate to GAE and dev_server.py? Is there a more sensible way that just mocking a web-browser and logging in? I don't need to authenticate or authorise other users, just the admin account for that app.
Is this OAuth? OAuth2? OpenID? Federated? Something else?
I realise this is a bit of an awkward question, since I'm not even sure what the right way to ask it is. However I am able to post to (in this example) /admin using a web browser after logging in with my (admin) gmail account. In that case the request (sent by Chrome) contains the cookies: __cfduid, ACSID (and what I think are Google Analytics IDs). Presumably one of those is responsible for my authentication. How do I get one of those?
And as a side question, if someone MITMs my connection (over http), can they hijack my admin session by reusing that cookie?
GAE likes OAuth2
Have a look at goauth2 . It seems to be the canonical OAuth2 library for Go. They provide a fairly comprehensive example at https://code.google.com/p/goauth2/source/browse/oauth/example/oauthreq.go .
With regards to your question "Presumably one of those is responsible for my authentication. How do I get one of those?", they state:
To obtain Client ID and Secret, see the "OAuth 2 Credentials" section under
the "API Access" tab on this page: https://code.google.com/apis/console/
And, finally, my humble opinion on "if someone MITMs my connection (over http), can they hijack my admin session by reusing that cookie?" is that you should never provide any authenticated connection (nor the connection that does the authentication) over plain http. Especially an admin section.
EDIT: To elaborate on the MITM question, make sure you use HTTPS for any login requests and subsequent requests for the same session, and make sure to set Secure and HttpOnly flags on your cookies.
OAuth2 if you want to use Google Accounts.
See here for details: https://developers.google.com/appengine/docs/go/users/overview (this section specifically deals with admin views)