I see most examples using it with form-based authentication (i.e. we load the mod_auth_form.so and other session modules). Is it possible to use this session timeout along with basic authentication (i.e. we load mod_auth_basic.so ) ?
Also, I know that the mod_session was introduced only after apache2.3, so this would definitely not be supported in apache2.2 I am fine even if it works just for apache 2.4.
It's not implemented in any other auth modules, but it's also unnecessary. Most other auth modules use HTTP basic auth, where the credentials are seamlessly transmitted on every subsequent request to the same host+context root.
But mod_auth_form needs to do a one-time capture/prompt/validate that cannot be propagated on every request. Hence the need to put them in a session store.
Related
I have a keycloak client sample-application. It has valid-redirect-uri https://sample-application.mycompany, a frontend service. This frontend calls backend service, sending JWT token in http header. Backend service checks allowed-origins in this JWT token. https://sample-application.mycompany is there, so everything works fine in production.
"allowed-origins": [
"https://sample-application.mycompany"
]
Now we are doing some e2e tests, and we are calling this backend, but from a different place - http://jenkins.mycompany. We have a proper JWT token, but backend service fails on allowed-origins validation, because http://jenkins.mycompany is not there.
My options:
add additional valid-redirect-uri http://jenkins.mycompany to my client - I don't want to do that, adding testing stuff to production clients seems bad
make copy of a client sample-application-testing, with additional valid-redirect-uri, use it for tests, delete afterwards
tried using server's private-key to generate my own JWT with extra entry in allowed-origins, but it failed later, because server validates this token
tried some magic with setting different Origin headers, but it seems impossible, browser protection I guess
Is there any other possibility?
Edit - the validation I'm talking about, checks if Origin header is in allowed-origins list. To be clear: this is not something I invented myself. This validation comes from keycloak-spring-boot-starter, here is the relevant fragment: https://github.com/keycloak/keycloak/blob/17117820cc14f87f5990ddce80ef38a0e2e7f314/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/AuthenticatedActionsHandler.java#L126
Keycloak allows one to add multiple multiple Valid Redirect URIs as well as multiple Web Origins. One of these should allow you to add the URL for your test server and have it appear in the Allowed Origins in the JWT.
More commonly, test environments will have their own copy of production servers so as not to interfere with production operations. This is pretty standard. For a CI/CD setup, it makes more sense to use some kind of a stub or mock validator (something that can be spun up locally) to avoid setting up a server entirely
Below is a screenshot of the settings in the Client configuration in Keycloak 19
I have an Apache server where users authenticate to a website through Kerberos/GSSAPI (mod_auth_gssapi). In the event of a user attempting to visit the site externally (not available on the network ldap server), I would like to fallback to SAML authentication (mod_auth_mellon), but am having trouble figuring out if this is even possible. I am managing the config for this in httpd.conf. Both work independently of each other.
I have seen a number of suggestions and threads, but nothing seems to work for me. The Mellon module github page recommends using a config to preemptively check for credentials, but in my case, credentials do not exist yet, and any IF statements executed would happen before I can retrieve them.
Essentially, I would like to do this:
User visits site
Apache checks for LDAP username credentials through Kerberos/GSSAPI
If Kerberos credentials do not exist, try to mauthenticate through SAML/Mellon
I do not know ahead of time which users' information will be available in my local AD server or attempting to access externally.
I would like to keep this on the Apache side if possible, though I may have to relent and run SimpleSAML or something after Apache authenticates.
I am expecting to have an authentication fallback of Kerberos to SAML in my Apache config. Currently, Apache defaults to the last authentication method listed in the config file. I would like an either/or scenario, depending on whether the first authentication method is able to obtain a valid user.
Any ideas, thoughts, solutions, criticisms appreciated.
I've setup proxied authentication for RStudio Server.
RStudio Server is redirecting to a middleware implemented using Express JS
The middleware creates a request to the authentication server and then parses the response from it.
Then the middleware adds the X-RStudio-Username header to the response, which is a re-direction to the RStudio. However, the header is added to the response from the middleware, and then the browser doesn't keep it when it redirects to RStudio Server
Since the browser request doesn't have the required header, RStudio requests the authentication again creating an infinite loop
How should I approach this case?
What would be the best way to add the required header for RStudio Server?
The browser won't add this header for you. You need to add it in the layer that proxies traffic through to RStudio Server. If you don't have such a layer already, you will need to add it using e.g. Nginx. This layer could authenticate the request using whatever mechanism your auth provider supports and add the X-RStudio-Username header (which we recommend renaming for security reasons).
Since you're using RStudio Server Pro, our support team would be happy to help you with this:
support#rstudio.com
You'll also be glad to know that we're working on SAML support for an upcoming release of RStudio Server Pro!
We are using HTTP server to route the request to Winchill PLM. There is a requirement to force the user to change the password once the login first time into the PLM. In order to achieve this, PTC ( Winchill PLM Vendor) posted a note stating that this can be done through Apache setting.
Could somebody help us on what is the setting to be done in Apache httpd conf file so that Apache validates the auth data with Winchill directory server and also force the user to change if it is first time login.
PTC ( Winchill PLM Vendor) posted a note stating that this can be done through Apache setting
hmmmm. but didn't tell you how to do this? Is this software you've paid for? If they state their application works with Apache then they should be able to tell you how to do this.
But, rather alarmingly, it is worth noting that the httpd does not provide any authentication functionality - that is handled by the auth modules (some of which are bundled with httpd). And you've not told us which auth module you are using. The simplest solution is file based - but it does not provide a method for setting password expiry.
A further issue is that regardless of which auth module you use, you are constrained to using HTTP (basic or digest) authentication if you implement authentication as an apache module - this provides a means for capturing a username and password - but not for negotiating a change of password. That's not just an issue on the webserver side - it's also how the browser will handle authentication.
route the request to Winchill PLM
That's not a very meaningful description of the architecture. I point this out here, as I suspect that the system might be handling authentication at the application tier (i.e. prompting for a username/password in the html) and that might require a specific configuration on the webserver, and it might provide a facility for password management.
But based on the information you've provided, either you or the vendor are very confused about how this application integrates with httpd.
I've setup security in my RESTFUL WCF services using Custom Basic Authentification (thus desactivating the iis Basic Authentification and not using Windows Accounts Login at all; my service is hosted by iis) using the following link.
blog link
I understand the consumers have to implement a client to pass credentials in the request header.
It is 64bits based encoded and we can see credentials passing in firebug network tab while debugging (it is always the same string encoded <=> same credential .......)
So, in addition, to enforce security I will add SSL to encrypt the url :
https://myrestfulserviceurl.com/Method
Now the consumers ask me why we don't just put the login and password in the url request i.e
https: // myrestfulserviceurl.com/Method?login=XXX&password=YYY
(also combined with SSL)
Thus the change requires to add login and password as parameters in my Operation Contract and call a method for authentification in my method "Method".. etc etc
My question is :
What is the difference (both scenarii will use ssl) between Custom Basic Authentification (credentials in request header) & simply passing credentials in url in param ?
I mean : I'm just asking myself why I do bother to implement Basic Authentification. Passing credentials in url or in header look similar : it's passing stuff in the request. But talking in term of security, it looks the same ?
Basic Authentification looks not more secure excepted the 64bits based encoding.
Correct me if i'm wrong.
I am just looking a reason why implementing Custom Basic Authentification.
Any idea/advise?
Thanks
The main difference that comes to mind is to do with how visible the data is and how long it is likely to be retained.
For instance, assuming SSL is terminated at your application server, values in the get parameters are likely to be automatically logged to your file system (in request logs for instance). Having usernames and passwords in there is not ideal as it makes it much easier for them to be leaked.
If SSL is terminated at a loadbalancer or some similar proxy, then the usernames and passwords could be saved in request logs on servers you may not be thinking about and probably have less control over.
By contrast, the Authentication header is much less likely to be logged to places you're not expecting.
I thought about doind this myself and decided against it because i wanted the Restful URL's to focus only on the operations and keep security out of it, for example I might want to re-use the same code on a different application.
Also Im not sure but i think there could be a security implication concerning replay attacks, if someone obtained the link then they could execute it in any http client. If you used the authroisation attribute in the http header you could avoid this by putting an expiration on it. Also i think its better to hide this information from the html page body.
The dude who wrote this http://lbadri.wordpress.com/2012/07/30/anatomy-of-a-simple-web-token-swt/, which is taken from his book "Pro ASP.NET web Security". Gives a pretty decent example of creating a token which you could then use in the http header "Authorisation", like: Authorization: Basic d2FsaWRAGssSGZ21haWwuY29tOn236dhbGlk