Looking for some advice about the use of client certs to retro-fit access control to an existing app.
Our company has an existing intranet app (classic ASP/IIS) which we licence to others. Up till now it's been hosted within each organisation that used it and the security consisted of "if you're able to access the intranet you're able the access the application".
I'm now looking for a way to host this app externally so that other organisations who don't wish to host it themselves can use it (each new client would have their own installation).
All user in the new organisation would have a client cert so what I'd like to do is use the 'Require Client Certificate' stuff in IIS. It allows you to say "if Organisation=BigClientX then pretend they're local userY".
What I would prefer is something that says "if Organisation=BigClientX then let them access resources in virtualdirectoryZ otherwise ignore them".
I would be very happy to buy an addon (perhaps an ISAPI filter ?) which would do this for me if that was the best approach. Any advice / war stories would be welcomed.
You likely want to do this. client certs are really intended for a second factor of authentication, but not the primary source. To say it differently, you still need to configure your app for basic or forms authentication.
The technology behind public/private keys is rock solid. However, you need a very mature IT organization who is dealing with certificate lifecycle management. If you do not have this, you will get untold failure scenarios because the certificate was expired, wasn't copied to the new computer, etc.
This is especially true in your scenario where your application is internet facing (in thee 'hosted' scenario) - you have little control about the issuance of the certificates to your users.
I've done something similar...
Generate the certificates internally from your org's domain controller. Export them both as PFX format for distribution, and CER format for you to import in IIS.
Distribute the PFX format exports along with the CA certificate for your DC, so your customers machines will "trust" your CA.
Now in the app properties IIS, go to the Directory Security tab, and under "Secure Communications" click "Edit". In there, click "Accept client certificates", "Enable Client Certificate Mapping", then "Edit".
Under the 1-to-1 tab, click "Add" and import the CER file. Enter the account you'd like to map this certificate to.
As for the "let them access resources" I'd advise doing that by the user account they're mapped through - that is, you can provide access to resources based on that account either through NTFS permissions, or through code by identifying the security context of the logged-in user.
Related
I'm planning to make the Tomcat (8.5) Manager accessible through a subdomain like this: https://tomcat.mydomain.com.
As you can see the connection is over HTTPS, but still, does this pose a security risk and is considered as 'bad practice'?
One think I did notice is that, by looking at the certificate for mydomain.com, you can see that https://tomcat.mydomain.com does exists. Which means there is not much security by obscurity.
Of course, it's important to have the tomcat accounts setup right and protected by a password, which I have.
Having the endpoint publicly accessible is not, in itself, a security risk. There are other considerations, though, that you might want to take into account when deciding whether or not to expose an administrative interface publicly:
How many people have credentials for the service?
Can all those people be trusted to have good passwords?
Can all those people be trusted not to re-use passwords across multiple sites?
Do you have lock-outs enabled (on by default if using Tomcat's authentication with the Manager app)?
Can the lock-outs be overwhelmed? (consider the lock-out implementation)
Do admins actually need public access to the Manager?
Are there additional layers of security you could add between the public and the management interface?
In general, I usually choose not to expose administrative interfaces to the public. I almost always require an administrative user to go through some other gate such as an ssh tunnel (with public-key-only access) before they can access any management interface, and then they most also authenticate a second time through that interface (i.e. you aren't automatically trusted just because you have the tunnel established).
If I were going to expose an administrative interface to the public, I think I would want something in addition to password-based authentication in the mix. Some other factor should be involved, whether that is something like a common 2FA solution like TOTP or similar, or TLS client certificates ("mutual authentication").
There is a presentation on the Tomcat web site about upgrading your credential security. There is sample code and configuration in there for how to set up TOTP within Tomcat's existing authentication system. You might want to read that presentation and consider whether you want to add protection like that to your administrative interfaces.
I'm trying to secure my k8s cluster, and I'm looking at client-authentication authorization support for k8s. My requirement is that I want to be able to uniquely identify myself (e.g. client) to the k8s apiserver, but everything I read so far about client authentication is not the solution.
My understanding is that the server will just ensure that the client certificate provided is in fact signed by the certificate authority. What if a hacker gets another certificate signed by the same certificate authority (which isn't hard to do in my org) and uses that to talk to my server? It appears that popular orchestrations like Swarm and k8s support this option and touted it as most secure so there must be a reason for doing this. Can someone shed some light?
It is not only verified that the certificate is authorized by the CA. The client certificate also contains the Common Name (CN) which can be used with a simple ABAC Authorization to limit the access to specific users or groups.
Also it shouldn't be easy to get a signed certificate. IMO the access to the root CA should be very limited and it should be comprehensible who is allowed to sign certs and when it happened. Ideally the root CA should life on a offline host.
Beside that it sounds like the CA is also used for other purposes. If it is so, you could consider to create a separate root cert for the client authentication. You can use a different CA for the server certificate by setting different CA files for --client-ca-file and --tls-ca-file on the apiserver. That way you can restrict who is able to create client certificates and still verify the server identity with the CA of your organization (which might already be distributed on all org computers).
Other Authentication Methods
As mentioned Kubernetes also has some other authenication methods. The static token file and the static password file have the disadvantage that the secrets have to be stored plain text on the disk. Also the apiserver has to be restarted on every change.
Service account tokens are designated to be used by applications which run in the cluster.
OpenID might be a secure alternative to client certificates, but AFAIK it is way harder to set up. Especially when there is no OpenID server, yet.
I don't know much about the other authenication methods, but they look like they are intended for integrating with existing single-sign-on services.
I'm adding support for JWT tokens in my Web Application, and I have an X509 certificate which it needs for signing those tokens.
I have rejected the idea of using the same certificate we use for HTTPs (see Can I use the Private Key Certificate of Web App to sign JWT?).
I think a self signed certificate should do the trick, in fact I can't see any advantages of a web of trust in this scenario (that doesn't mean there aren't any, I just can't think of any).
The web application runs on a farm of web servers. My current plan is to generate a self signed cert and put the X509 certificate into the certificate store in Windows on each machine. Our IT department are checking, but they think they can roll that out to all the Web Servers in the farm using Group Policy. So this seems like a feasible plan.
The certificate store in windows looks pretty confusing to me. I think there are two options:
1) Put it in "My" store for the user under which the IIS App pool run. There are many app pools, so potentially the certificate will be in many stores.
2) Put it under the LocalMachine store, and then grant explicit access to the specific certificate for the IIS user(s).
3) Something else I can't think of.
Is there a "correct" place for these type of certs, and if so where is it?
The usual CertificateStore for signing certificates is the My store. I normally place them in LocalMachine location, but it is probably safer to put them in the certificate store for the Application Pool identity itself.
I would then give the Application Pool read-only access to this certificate only (right click certificate, then 'All Tasks' > 'Manage Private Keys', then add your Application Pool identity and give 'Read' permissions only.
I'm new to WIF - sorry in advance if my questions seems to be very basic...
I have a 1 WebSite lets say localhost that require username/password authentication. Access to //localhost/ForSecuredClientsOnly should require only client certificate to access the site.
AFAIK client certificates authenticaion is handled by IIS, how should I handle this problem if I want to use STS?
My ideas:
Use 1 STS, set IIS to Accept certificate (not to require) and read certificate in STS and figure out whether user can access the resource.
I was reading through http://msdn.microsoft.com/en-us/library/ff359105(v=PandP.10).aspx and
http://blogs.msdn.com/b/eugeniop/archive/2010/04/03/wif-and-mvc-how-it-works.aspx but when I'm already logged in to //localhost and try to access //localhost/ForSecuredClientsOnly STS thinks that I'm a valid user.
I'm returning new Redirect result from ForSecuredClientsOnly (path from SignInRequestMessage, since user does not belongs to group X) but the realm is always: //localhost/ (probably it's expected behaviour and reason why user is authenticated ...)
Use 2 STSs and move //localhost/ForSecuredClientsOnly to //securedClients.localhost. I don't really like idea of having 2 STSs though
Have 1 STS and create to websites pointing to the same STS. I hope that then in STS I'll see that sign-in request is going from different realm and then perform either username/password of client certificate authentication? I would also prefer not to use that option since it's not ideal if I need to create new website per section of the site that requires different authentication.
Questions:
I would like to make idea number 1 working but how can I pass different realm depending on site subsection, I see that I can set HomeRealm property on SignInRequestMessage but how can I later read it in STS? (User.Identity.IsAuthenticated is always true in STS if I already logged in to //localhost).
Should I be using HomeRealm at all to distinguish between site sections?
If you have ideas what's the best approach to read and validate client certificate in STS please let me know. Currently I'm thinking that I should check whether certificate Thumbnail is one of the certificates that I'm allowing - store collection on client certificate Thumbnails in database?
I appreciate all your input.
I think it will be worth looking at the Starter STS community project at Codeplex.
In my application, I just want to upload some data on the server without interacting with the user.
How do I silently upload data on the server in J2ME without asking the user for Internet usage?
In order to upload silently, the user must approve at least once that it allows you to connect to the internet, as specified by the MIDP 2.0 Security Architecture.
First you have to sign your Midlet with a certificate from a Certificate Authority (commonly refered as CAs) as Verisign, Thawte, Java Verified, etc. You have to choose your CA depending on the devices you are targeting. The device will just recognize the CAs installed as root certificates. If it doesn't have the root certificate of the CA you chose, it will not be a secure third-party application. This is explained in simple steps in the Nokia Wiki
The second step is to set in your JAD file the next line
MIDlet-Permissions: javax.microedition.io.Connector.http
This will ask for http connections permission since it is installed.
In this way the user will just be noticed once, and will be allowed to set the permission permanently. Some devices will not allow a permanent permission if the application is not signed.
This is impossible. All the phones ask the user before letting an application use internet services.
One possibility could be signing the application somehow, but that would work on very few phones, if any.
If your application is signed by Java Verify or similar you will be able to let the user say they allow all future http connections, rather than having to authorise them all singularly.