I need to make something like ssl certificate authentication at website. As far as I understand my task I need to get user's ssl certificate and send it to server what will decide can user be authenticated or not.
How can I get user's SSL by javascript and send it to server? Is it possible at all? Or maybe my approach is wrong or I do not understand my task correctly.
Maybe my solution will be useful for somebody. At IIS server configuration we need to check require users certificates checkbox. Than user when opens site will be asked for a certificate form personal certificates storage.
After if public certificate can be accessed from a Request object (c#) at server. From it we can get user's details and allow or deny login
Related
Am i out of luck or is there an option to specify that only a single path/endpoint should require client certificate ?
The scenario:
IdentityServer4 gives our users the option to sign in multiple ways (Username/Password, Azure AD or ClientCertificate)
The first two are working as intended, but the certificate paths does not prompt the user for his/her certificate, i know its possible with IIS but we want to run this using Kestrel.
If i setup the projects kestrel setting to require cert all endpoints requires it, this ruins the user experience when signing in with username/password og azure ad.
Are there any options for setting only out localhost/certificate path to require certificate and then in turn prompt the user to provide their cert when being redirected to that paths endpoints if there is no cert present in the request?
Resolved it by setting up two hosts, and capturing the request in the certificate challange endpoint and checking the connection, if there's no certificate present AND the connection is using the non-requirecert connection i redirected the context to the right connection and was then prompted to supply the cert and login works as intended.
I am currently working in IBM's Domino(8.52). I have the website set up with SSL and to accept certificates. For the time being I am allowing "Anonymous" access over SSL. The user is prompted to select a certificate when trying to get to web site. But if the user selects cancel button, the user is returned to web site as an Anonymous user. Is there any way to control where the user will go if a certificate is NOT selected? I would like a server wide solution but would like any possible coding ideas.
V/R,
Kev
How's the weather in VA?
The problem is that you are using the promoteunknowncerttoanonymous=1 ini setting; so you will not see the names on cert of users unless they have a corresponding x.509 loaded in the person doc.
Remove the ini setting, Disallow anonymous and username/password from both 80 and 443 in server doc, make sure your root x.509 cert is in the keyring, and you should start seeing the usernames from the certs. You will now need to manage the Default setting in all db ACLs, and Anonymous will not be used.
I was wondering if the twisted webserver offers the possibility to restrict access to some resources using client certificate based authentication and to allow access to other resources without certs.
I searched trough the questions and found this posting: Client side SSL certificate for a specific web page
Now my question is if someone knows if twisted has implemented the ssl renegotiation and how an example would look like.
Or has there been a different approach since then?
Just to make things clear and to give additional information:
What I actually want to achieve is something like this:
A new user visits a site and has not yet granted access to the resource because he has no token yet that allows him to view the site.
Therefore, he gets redirected to a login resource that is asking for a client certificate. If everything is correct, additional data retrieved from the certificate is stored in the session, which makes up the token.
He then gets redirected back to the entry site, the token is validated, and according to his authorization level specific content is displayed
If I understood you correct Jean-Paul, this seems to be possible to implement with your strategy, right?
Correct me if I'm missing something or doing it wrong.
It doesn't seem to me that SSL renegotiation is particularly applicable here. What you actually want to do is authorize a request based on the client certificate presented. The only reason SSL renegotiation might be required is if you want the client to be able to request multiple resources over a single persistent HTTPS connection, presenting a different client certificate for each. This strikes me as unlikely to be necessary (or at least, the reasons for wanting this - rather than just letting the client establish a new HTTPS connection, or just authorizing all your resources based on a single client certificate - are obscure).
Authorization in Twisted Web is straightforward. Many prefer a capability-like approach, where the server selects a resource object based on the credentials presented by the client. This resource object has complete control over its content and its children, so by selecting one appropriate for the credentials presented, you completely control what content is available to what clients.
You can read about twisted.web.guard in the http auth entry in the web in 60 seconds series.
This will familiarize you with the specifics of authentication and authorization in Twisted Web. It will not tell you how to authenticate or authorize based on an SSL client certificate, though.
To do that, you'll need to write something similar to HTTPAuthSessionWrapper - but which inspects the client SSL certificate instead of implementing HTTP authentication as HTTPAuthSessionWrapper does. This will involve implementing:
IResource to inspect the transport over which the request is received to extract the client certificate
implementing a credentials type which represents an X509 certificate
implementing a credentials checker which can authenticate your users based on their X509 certificate
and possibly implementing a realm which can authorize users (though you may have written this already, since it is orthogonal to the authentication step, and therefore is reusable even if you don't want to authenticate with SSL certificates)
This functionality would be quite welcome in Twisted itself, so I'm sure you can find more help from the Twisted development IRC channel (#twisted-dev on freenode), and I hope you'll contribute whatever you write back to Twisted!
We have a webserver in a DMZ hosting an IIS website. The website talks to a middleware machine in a private domain, which is hosting WCF services.
When the webserver tries to communicate with the middleware machine via a TCP binding, we get the following error message,
The server has rejected the client credentials. The logon attempt
failed.
The website uses an AppPool account from the private domain (DMZ trusts private domain). Forms and Anonymous authentication are enabled.
My question is, would the middleware server be able to authenticate valid credentials (hopefully the appPool credentials), even through they originated from an untrusted domain (dmz)??
#marc_s is right in his comment. It's not just a WCF thing though. it's security in general.
Just look at it from a conceptual point: "authenticate valid credentials" is not what is happening. The middleware service gets credentials. The question is then if those credentials are valid or not. In order to determine validity it needs to known it or ask something that it trust to validate it for him. Asking an untrusted party doesn't work since you can't determine if the answer you get is a valid answer or not. In your case there is no place to determine if passed credentials are valid or just a random token.
If you want to allow unvalidated credentials to pass you should really remove the authentication/authorisation all together.
I want to be able to set up a web application to automatically (i.e. on a cron run) send a POST request to a remote website. The remote website requires a username/password combination to be sent as part of the POST data. I want the web application to be able to make the POST requests of the remote website without requiring the user to provide the password to be sent with the POST data, each time the request is made.
It seems to me that the only way to do this is to store passwords directly in the database, so that the cron run can execute a POST request that includes the password as part of its POST data. Without storing the password in some form in the database, it seems it would be impossible to provide it in the POST data, unless the user provides it each time the request is made.
Question 1: Am I mistaken and somehow overlooking something logical?
Question 2: Assuming I have to store the passwords in the database, what is the safest procedure for doing so? (MD5 and similar one-way encryption clearly will not work because I have to send an unencrypted password in the POST request.)
Thank you for your help!
a. if you don't know the password... you can't authenticate, that's the idea of a password !
b. if you need to know the password - you need to save it in a decryptable way - hence - less secured.
c. if you own the site, you can use a cookie with a very long timeout value, but - you still need to authenticate at least once.
d. unless you're guarding money / rocket science, you need to encrypt the password and store it in the DB and decrypt it every time before use, at least you are guarded from DB theft.
e. make sure you're authenticating over secure channel (as https) so the password will no be sent as clear text.
One good solution is probably to use SSL (i.e. HTTPS). You can create a certificate authority on the server side, then have this certificate authority sign a client certificate that you generate. Make sure the HTTP server is configured to trust the newly created certificate authority.
Once this is done, you should install the certificate on the client side. The client must present the certificate when talking to the HTTP server. You have to configure the HTTP server to require a trusted certificate when POSTing to your secure URLs.
Awesome example of how to do this with Apache HTTPD is posted right here!
The document I linked doesn't describe how to set up the certificate authority and create self-signed certificates, but there are tons of examples out there, for example here.
This is a good solution because:
no passwords are stored in the clear
if the private key of the client's certificate is stolen or compromised, you can revoke it on the server side
The key here is that the client is providing its credentials to the server, which is the opposite of what is usually done in a browser context. You can also have the client trust your newly created certificate authority so that it knows it's talking to the right server and not a man in the middle.
Given that you have to send the password in clear-text and do it repeatedly without user-interaction you'll need to store and retrieve the same from a data-store (file/database/memory).
What you really need to consider is the last-line-of-security of the password store.
Whether you encrypt it or not doesn't matter. The person/program with access to the data or the cipher key will be able to read that password.
Sort this issue out, document it - (this becomes your security policy for the app) and then implement it.
Security is only a level of difficulty you implement to lessen a risk.
Fortunately, Tumblr now implements OAuth, which solves this problem.