I found this answer on how to use Web.Config to make IIS require SSL client certs for a specific MVC controller but I can't figure out how to make it work if the user visits any other controller first.
The purpose of this requirement is that the client certificate is only used for login to access secured portions of the application. Users who are not logging in should not be prompted for a certificate.
Example: SSL cert required for Auth controller
If the user goes directly to domain.com/Auth they are prompted for a certificate as intended. However, if the user goes to domain.com/Home then clicks Sign On (sending them to the Auth controller) they receive a response of HTTP 403.7 indicating the site requires a client certificate.
Turned out to be a browser caching issue.
Related
I've a sub-application that I want to use windows authentication.
I want that login box pops up even in the domain when the person first reaches the page.
When I turn off Kernel-mode authentication, the login box pops up, but fails with error 401 Not Authorized after 3 login attempts.
If I turn this on, It doesn't even asks for the password,I believe this is due the computer is in the servers domain and the credentials are passed automatically.
Is there any possibility to show login form for all users, including domain users?
In the image below are my server configs.
Windows Authentication is normally handled by IIS. This is the way it works:
Client requests the page.
IIS returns a HTTP 401 response, with a header saying that it accepts Windows auth.
The client's browser automatically resends the request with the users credentials (as long as the site is trusted).
IIS verifies the user and passes the credentials to the application.
This is all designed to be seamless.
If you want the user to be prompted for credentials all the time, then either:
Make sure your site is not trusted (not in the Internet Options Trusted Sites or Intranet Sites). But you may not be able to do that.
Don't use Windows authentication. Uses Forms authentication and make a login page where the users can enter their credentials. But that means that you will have to verify the credentials against Windows or Active Directory yourself in your code.
If you use #2, then also make sure to use SSL on your site since passwords will be sent in plain text.
You can use Basic authentication. It will prompt the user for credentials and once entered, it will give you a seamless experience.
However, the disadvantage with basic auth is that it sends the password in plain text to the server. You can use SSL certificate to encrypt this information.
I've written my own login app to protect my api following the oauth-login-app example.
I've implemented the web server flow and everything works great.
My question is: how should I handle an authentication failure at step 3? How do I tell he client app that the authentication failed? The user could either press the cancel button, or refuse permission or just enter the wrong details.
When you initiate OAuth 2.0 (dance) with
/authorize
the user-agent land on /login page (created/hosted by you),
post redirect.
enduser(user-agent) submits the username/password
to the page hosted by you. Here you collect the credentials and
submit to Apigee, and if authentication fails, send a HTTP 401
response. Now your application should be in position to re-render
the login page and with a flash "invalid credential".
Now coming to if user is authenticated but rejects the authorization request in
consent page, you should redirect to the "redirect_uri" provided
by client, with error code.
How do I tell he client app that the authentication failed?
The login app will redirect the control back to the application redirect URI - with added error code/description in the URL as hash parameters. In case of success the URL is appended with code or token.
You can do this redirect from your login app directly but I would suggest to make the redirect call first to an Apigee Proxy and let Apigee Proxy send the redirect back to app. Both in case of success and failure. In this way you will have the benefit of using Apigee analytics that helps your understand how many OAuths failed for what reason etc.
EDIT:
You can use the same GenerateAuthorizationCode proxy you have built for the success flow. When login fails or succeeds, in either case you need to pass that information to this proxy. Generally the login app and this proxy should share this information using a common session store. You can not pass this information just using a redirect parameter because that can be changed by the client user agent. When you redirect to the GenerateAuthorizationCode redirect proxy, do so by appending a random session ID in the URL. That id can be used by the GenerateAuthorizationCode proxy to look up the login status from the session store. Then you can either send back a redirect with error or a proper oauth code based on if the login was successful. An easy implementation of the session store can be done using a distributed caching resource in the apigee gateway. Login app can put/get the session using an internal API. While the proxy can use policies to retrieve the session information.
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 have a virtual folder containing an administration application, like
https://www.mysite.com/alpha
which requires SSL. In the IIS manager properties for the folder, under "Authentication and access control", Anonymous Access is disabled and "Authenticated Access" is set to "Integrated Windows authentication."
When I connect to the site in Chrome, I receive two login boxes. The first is from mysite.com/alpha:443, and the second is from mysite.com/alpha:80. Firefox appears to re-send my credentials for the second box so it is never shown.
Any ideas why I'd be required to log in twice?
If you require SSL for authenticated users on your website (for any reason), then the best solution is to always have your "Login" page on https://. That way when they log in, they are instantly secure. The reason for this is because of the native design of SSL. It separates/secures it's self from the non secure version by not passing authentication states between http and https.
you will also have to write some logic to redirect returning authenticated visitors to the secure page (IE: visitors who can return authenticated from a cookie).
EDIT:
Since your using windows authentication, it's probably easiest to simply redirect ALL incoming http traffic to https. This means your entire site will be over SSL and will be inaccessible via http (other than to redirect to https)
I wrote a Blog Post on forcing a website to use WWW in the web address, but it can also be ported to forcing https.
Yep,
The one uses SSL, the other not.
therefore, you are not allowed to share the credential cache from a Secure session, with the one of the unsecure session.
if you require SSL, then directly redirect the users to the SSL website.
I intend to use SSL on the login form so that the username and password is encrypted during user login.
But, after the user has been authenticated, if I return to HTTP, the Autentication Cookie will be passed from client to server on each request. How safe is this? Obviously i'll use SSL on pages where the user is entering sensitive information, but for most of the time, for performance reasons, i'll just want them to remain authenticated and use HTTP.
I note that if I set RequiresSSL="True" in my forms authentication section in web.config then the authentication cookie is not passed if I use HTTP so I cannot identify the current user.
I guess my question is:
"Is it bad practice to set RequiresSSL="false" and allow the Authentication cookie to pass over HTTP"?
The forms authentication cookie is encrypted and checksumed with the machine key for your server if you set protection="All", so it's not particularly bad to drop back to HTTP.