I want to use a squid to speed up a site with authentication, (user have to login/password on the application first before getting any information).
The slow part of the site are namespaces provide by a rest api:
/api/1/ns_xxx
Does squid allow to serve pages through/after an authentication ?
Squid can totally manage authentication. See the FAQ from squid. The proper configuration is login=PASS at the cache_peer level
Related
I've been been working on a website with a pretty complex setup:
3 backend servers coded in java with netty running the main application
A ngnix reverse-proxy doing load-balacing
A seperate nginx webserver serving static content
As proof of concept, I want to have some important files like a big super secret document on the nginx-server serving static content but only allow authenticated users to access that file and I honestly have no clue to do it...
Try
nginx auth module
For more detailed usage NGINX Authenticated User
We have built a WCF service for an application and everything is working out well, using WSHttpBinding. We now have been asked to make sure the communication between the Web Application -> WCF -> Database is secure and have been asked to use SSL. Along with that they are requesting we make sure the WCF service can not be accessed by another application.
If we setup SSL, does that block others from trying to get in, or we do still need to setup the clientCredentialType setting on the service? Also the entire application (site, wcf, db) will be within a company's network, so if we setup the clientCredentialType="Windows" which account is used, how does WCF know to allow the website to talk to it, which Windows account are they using, or this an account we need to setup?
Thanks.
SSL has nothing to do with Authentication or Authorization.
It does 2 things:
prevents third parties from intercepting your traffic.
verifies that people are who they say they are.
The requirement "make sure the WCF service can not be accessed by another application" needs to be handled through some Authentication / Authorization mechanism. You could use Basic or Windows depending on your needs.
Since you're in the company's network, I'd attempt to use Windows Authentication. This will force clients to be authenticated through your domain, however it looks like you don't want just any domain user to have access. In this case, you need to set up either Role based authorization, or user based. Either war, you can drop a Web.config file into the same folder as the WCF service endpoint specifying what accounts are authorized. Other users will see a 401 Unauthorized.
This is the general approach I'd take.
A number of Countries have implemented electronic id cards, that their citizens can use to securely access online facilities like banking.
I am interested in learning how to support these cards, but tracking down documentation on how to do this from an IIS hosted website is a real PITA: In MSDN for example the bulk of the smartcard documentation covers the end to end scenario of linking smart cards to domain logins in a corporate environment.
I am just trying to authenticate the holder of - for example, a Spanish DNI-e card and perform an OSCP validation of the card via http://ocsp.dnie.es/
Now, its seems that, rather than explicitly detecting the smart card insertion, I need to create a login page on the server with SSL client authentication forced - but how do I configure one request to require ssl client authentication and to pick the correct client certificate?
Indeed, configure your server to require client certificate authentication. You will receive the client authenticator details in the headers.
You can force to only accept specific certificates by configuring the public root certificate of those client certificates on the server and removing all others that you are not interested in. In the authentication request going from your server to the browser, only the root certificates are listed that are trusted on your server system. The client browser will only offer client certificates that are somehow related to that root.
In an Microsoft environment you would configure your IIS to require SSL on your login page. Additionally, require SSL client authentication using a certificate.
I am a developer working on an ASP.Net Web Application that uses forms authentication.
In my experience I have always worked in an environment where we use SSL to protect the web pages according to permissions.
In my new company my manager has asked me whether we need SSL and can we do without it.
We are using a private network for the application and do not anticipate any heavy duty hackers.
However it is useful that permissions protect webpages from unauthorised users.
So what is the best way of tackling this?
That depends on your security needs :-).
If you trust everyone who has access to the network (this includes people like cleaning staff and external contractors) not to install sniffing software and do bad things with the passwords and personal data they sniffed, then you can do without TLS. Otherwise you need it. That's up to your manager to decide.
If it's a private network (i.e. Intranet and everyone is 'trusted') then like #sleske mentions you don't have to use SSL for anything.
That being said my question is what is the manager's reasoning for not using SSL where it makes sense? If it's cost then you could have your own (company) CA rather than using a commercial CA. Most places I've worked have setup a CA on one of their server's (which may or may not be trusted by VeriSign or one of the other commonly used CA's) and that was used to issue certificates to internal web servers. All computers on the Domain were setup to trust the company's internal CA.
As far as SSL/permission protection of your pages/content:
SSL protection is a separate topic from 'permission' protecting your pages. SSL is just encrypting the http traffic from the client (browser) and the server. Protecting your pages is up to you using permissions and checking that the user is authenticated, the mechanisms for this don't change based upon (not) using SSL.
I’m developing an Intranet application and I want to make a secure authentication.
One approach can be use “https”. The problem is that the server doesn’t have a trusted certificate, therefore is a bit annoying for the client because the browser doesn’t trust in the certificate and complaints with a scary message.
Using http will compromise the user password but it can be combined with “Digest access authentication”
What do you think?
As of November 2015 you can't buy certificates for internal domains so as far as I know the only option is to pre-install the certificates on clients. Not a great solution.
Another possability if you want to keep your internal domains private is to create a public domain: mycompany.com, and then run your own DNS server internally that resolves your internal domains: accounting.internal.mycompany.com, hr.internal.mycompany.com and so on. Then I believe you can use a wildcard certificate for mycompany.com. I haven't tested this solution.
These are (y)our options:
If you have mostly Windows hosts, you can Distribute Certificates
to Client Computers by Using Group Policy | Microsoft
Docs
and use your own self-signed certificate in this way.
Non windows users or Windows machines not in the domain will have to
go through the hoops and warnings of either installing the
certificate properly manuallly or allowing the self-signed certificate.
A bad user experience.
You use a proper domain name, a real certificate and a messy DNS
configuration where www.mycompany.com resolves to an external site,
but wiki.mycompany.com is an internal site (But please, please don't put the internal
address for wiki.mycompany.com in an externally visible DNS record!)
You don't use HTTPS at all and use HTTP. Possibly by inventing your
own security for login pages (Yikes!)
They all suck.
Especially if you want to distribute an enterprise-ready onsite app, and you don't know the customer's network and DNS configuration beforehand.
Purchase a domain and trusted certificate? They are really not that expensive anymore if you shop around.
Having said that, digest access authentication is reasonably safe for authentication. Using http rather than https, all of the information you send across the wire will be plain text even if the password is not. Anyone that can plug a laptop in to your intranet running an application such as WireShark can view all of the information sent back and forth. If you care about that information not being compromised, http will not meet your needs.
You have these options:
Purchase a trusted certificate.
Or, generate your own root certificate, install it in browsers on all intranet computers (you should be able to do it since it's intranet), generate your own server certificate signed with your own root certificate. This is actually what companies often do.
Note: Digest access authentication is not helpful if you want to have form authentication (a HTML form with user, password, login page using the visual style of your app, nicer wrong-password error reporting, possibly additional features such as "remember me" or "forgot password").
If you need it to be a fully secure, you should purchase the SSL certificate.
From the wiki link you provided:
Disadvantages
Digest access authentication is intended as a security trade-off; it is intended to replace unencrypted HTTP Basic access authentication which is extremely weak. However it is not intended to replace strong authentication protocols, such as Public key or Kerberos authentication.
I think there's your answer :)