I need to upgrade an activex smartcard authentication in IE to a Blazor web authentication in Net 5. It is mandatory an Authentication via SmartCard with PIN. I setup identityServer4 as for Configure certificate authentication in ASP.NET Core but when login page is called, the smartcard reader doesn't read the smartcard inserted in the client. I need to validate the login on the server against the certificate to be read in the smartcard on the client.
There is a way to accomplish this goal? Or somehow through a blazor client-side page? thanks
If you mean to read the smartcard info from a controller in identity server, you would use:
var cert = Request.HttpContext.Connection.ClientCertificate;
I'm fighting the same struggle. I was able to make IdentityServer4 do smartcard authentication, but it wouldn't pass a token back. I modified it to use a different method of authentication but I get the info off of the smartcard. It's somewhat working for me. I wish there was a better way.
The customer required to abandon identity server and I was forced to manage a way to solve the problem.
I created a WebApi and i configured it to require a certificate as for https://learn.microsoft.com/en-us/aspnet/core/security/authentication/certauth?view=aspnetcore-5.0 .
Any method you expose in the WebApi require the certificate and you can get it through
X509Certificate2 clientCertificate = await HttpContext.Connection.GetClientCertificateAsync();
and process it according your needs i.e. returning the thumbprint.
On the server you need to install the certificate authority relating to your smart card in the trusted certificate root in order to webapi works, otherwise you get a "Forbidden" response (https://learn.microsoft.com/en-us/skype-sdk/sdn/articles/installing-the-trusted-root-certificate).
On Blazor client side you just call the webapi endpoint and smart card is read and you type the right security code to get the response you need
Related
I have a Next.js website I'm working on and a dotnet core API connected to a SQL Server database. I have a login page and intend to create a page to add new users and was wondering how I could do this using dotnet core identity? I added the NextAuth.js package thinking I could utilize it, however it seems to work best if connecting directly to the database and not go through an API.
I managed to return the token to NextAuth.js but I don't know where to go from there. How can I use next-auth to manage the session? Or is there a better way to go about doing this without using NextAuth.js?
My reason for using dotnet core identity is because it already has support for roles and setup is fairly simple and makes authorizing different sections of the API easy. Based on a user's role, they should be authorized to access certain routes or view certain pages.
I tried looking at the following doc from microsoft Intro to auth for SPA, but it's not exactly clear to me how I can manage the session.
First, generally, when we using JWT authentication, the workflow as below:
Client sends a request (which contains the user information, such as: name and password) to server for token
Server receives the user information and checking for authorization. If validated success, server generates a JWT token.
Client receives the token and stores it somewhere locally.
Client sends the token in the future requests.
Server gets the token from request header, computes Hash again by using a) Header from token b) payload from token c) secret key which server already has.
If ("newly computed hash" = "hash came in token"), token is valid otherwise it is tempered or not valid
After configure your application uses Identity and JWT authentication. When a User login, you could send the user information to the server side and check if the current user is valid or not, then generate a JWT token, and on the client side you could store the token in the web storage. After that, when you want to access the resource by passing this token into the authentication HTTP header. More detail information, please refer to the following article: JWT Authentication In ASP.NET Core
I'm working on securing some Azure Functions endpoints. I tried with Certificate, but I hit a few walls
In the FunctionsStartup (from which derives my startup) I could not find a way to connect my AddAuth and Auth methods/classes. (I tried to search, read more on this topic, but all the answers were either for web API other type of Authentications)
I tried to check for the existence of a certificate at least, but that didn't worked either. I tried to get the certificate from request-context-connection-ClientCertificate or to read it from headers. Didn't worked locally or on deployed version. The certificates are always null.
I saw that there are some options to secure it with AD(also with facebook, google and so on), but first I'm curious if someone successfully implemented another Auth method, more like in a classic web api approach (JWT tokens, certificate, other similar stuff)
Access restrictions enable you to define a priority ordered allow/deny list that controls network access to your app. The list can include IP addresses or Azure Virtual Network subnets. When there are one or more entries, there is then an implicit "deny all" that exists at the end of the list.
Also you can request a client certificate when the client request is over TLS/SSL and validate the certificate. This mechanism is called TLS mutual authentication or client certificate authentication.
First, your App Service plan must be in the Basic, Standard, Premium, or Isolated tier.
Secondly, enable client certificates:
az webapp update --set clientCertEnabled=true --name <app_name> --resource-group <group_name>
Finally, Access client certificate. App Service injects an X-ARR-ClientCert request header with the client certificate. Your app code is responsible for validating the client certificate.
For more details about how to configure TLS mutual authentication for Azure App Service, please refer to this article.
I'm trying to figure out how to set up my Azure Web App to require client certification. The idea is to force the client's browser to send a SSL certificate (that's installed on their machine) to the web app. The web app then validates attributes in the certificate to make sure the client is authorized to access the web app.
The purpose is to enhance the security of our web app since user cannot login from a device that doesn’t have the SSL cert explicitly installed (even if they have the username/password somehow).
I'm not sure where I should begin with this. I understand SSL handshakes and the highlevel concepts but I don't really understand how to implement this in my current ASP.NET MVC web app. A tutorial that would point me in the correct direction would really help out. Or even the steps required to achieve this as I am not sure where to begin (setting up SSL certificate with IIS? Getting client to send the SSL certificate? Where did the certificate come from?) All of these questions...
UPDATE: I found this article:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-configure-tls-mutual-auth
But I don't know where to begin...
Is there a way to use the native WindowsIdentity/WindowsPrincipal inside of a C# application running on a corporate domain to be able to request a SAML token from the domain's ADFS server so that the C# application can then make subsequent calls to WS-Federation calls in a service provider that has been federated with the ADFS server?
Seems like we would use WIF to contact the ADFS server to get a token. Is there a way to supply a Kerberos ticket to the WIF, rather than using a username/password?
Looking at WindowsIdentity.GetCurrent() I can see that the user is logged in using kerberos, but don't see how to configure the WIF call to ADFS to use kerberos to automatically get a SAML token without a username/password set of credentials.
Does https://blogs.msdn.microsoft.com/alikl/2011/09/30/how-to-use-ad-fs-endpoints-when-developing-claims-aware-wcf-services-using-wif/ help?
You should make sure you have an endpoint enabled that can do windows integrated auth via kerberos enabled. Something like /adfs/services/trust/2005/windowstransport or /adfs/services/trust/13/windowstransport . You can check that via parsing the /adfs/services/trust/mex endpoint. Occasionally some of these endpoints are disabled by a sysadmin.
Using a kerberos ticket as the credential for the endpoint means your app needs to be running on corpnet with access to domain controllers so it can obtain a ticket for AD FS. If the app use is not required outside corpnet this might be OK for you. Else you need to consider how the app behaves/authenticates inside and outside corpnet.
Have a look at https://www.microsoft.com/en-gb/download/details.aspx?id=4451 for samples but they'll need modifying based on version of WIF you plan to use as outlined in https://learn.microsoft.com/en-us/dotnet/framework/security/guidelines-for-migrating-an-application-built-using-wif-3-5-to-wif-4-5
Lastly you should consider if its possible to use OpenID Connect and OAuth2.0 instead of WS-Federation/WS-Trust in your scenario. If yes, you should review the information at https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-scenarios-for-developers
I am going through Web Api in Asp.Net using Visual Studio 2013.I am using Asp.Net Web Api Template.I am able to build a simple client that can register and login with the API.I got Bearer Token When user login and i send this token in header for accessing data from my API.Now i wanted to know how this Token in get/post request is working in API side.
When i made this API work with Windows Azure Storage I have not seen any table that saves these token corresponding to users.so where these token goes.
I can't speak for these particular tokens, however other token frameworks that I used (DotnetOpenAuth) just encrypt the username and access scope and create a ticket out of it.
It is similar to what the Forms Authentication module does. There is also no table to map issued cookies to users and this is because the cookie can just be decrypted at the server side.
Think about the token as a standalone encrypted information rather than an internal id to data that has to be persisted at the server side.