We have a solution / security requirements from our customer:
1. Multi-Factor Authentication: Users digital identities will be established by authenticating users using their assigned username, password and an approved Multi-Factor Authentication (MFA) method.
2. Conditional Access to restrict connectivity from Home PCs, etc:
a. For users on new devices: Access will be restricted to authorised devices. Authorised devices will be verified using a device certificates (sometimes referred to as a client certificate) issued by the customer’s Public Key Infrastructure (PKI) service when a device is first enrolled.
b. For users on older devices: Access will be restricted by an IP address range.
We have prototyped the use of an Azure Application Proxy (to meet Requirement #1 for MFA above). However, through testing we’ve found that we can’t get the certificates to work via the proxy.
Installed the Cert on the JBOSS app server sitting behind the AAD PRoxy. This then gets blocked by the proxy.
I would like to register the Cert (or multiple certs) on the proxy, to allow secure access from the client devices to the Azure platform (App Servers / Proxy or gateway) .
There is no option in the Azure AAD to install a cert.
Related
I would like to have your mind about an implementation. Thank you in advance for any suggestion :)
**Scenario**
I have a set of APIs. They are accessible via REST and protected by OAuth2. I have also a list of machines that needs to access them.
Question
On machine’s side, which is the best solution to access them? Should I implement a client certificate authentication or OAuth2 is a suitable solution?
**My doubts:**
In case of hundreds, thousands of machines, the certificate
management become too complex/costly?
Should I use a certificate for each machine or one certificate for more than one?
How can I deploy smartly the certificate to each machine?
I like the idea to have the mutual authentication, but I’m afraid is to heavy to maintain compared to the OAuth structure. I plan to use Microsoft Azure as cloud service.
Thanks!
I would say the important factors here are client identity and privilege:
You may have many client machines
But do they represent a single identity, eg a cluster?
And do they all have the same privilege?
By default I would aim for a solution where all client machines with the same privilege present the same credential / identity. The APIs can then authorize requests based on the client identity, provided in the access token.
The standard OAuth solution is Client Credentials flow, where clients each send a secret to the server.
If required (and supported by your Authorization Server) you can use a Mutual TLS form of Client Credentials, via the Client Assertion Profile. This usually boils down to a private key signature sent by the client, which is contained in a whitelist configured on the Authorization Server.
I have an ASP.NET MVC application that authenticates users against Active Directory.
As I understand this is the process happens when a user logs on to his computer:
User enters credentials on the local machine.
Local machine checks if it already has an authentication ticket for these credentials.
If not, it contacts the first ADS server it can find that offers kerberos authentication functions
The ADS machine checks the credentials against the LDAP database.
If they check out, kerberos returns a TGT (ticket-granting-ticket) to the client machine
For a certain duration set in AD (usually 8~10 hours) this TGT will bypass any credential checking in case the local machine user wishes to connect to resources that require permissions not present in his bare user account (i.e. group memberships, additional machine and share access, etc.)
My question is how does IIS know about the TGT when the browser is making a request to it for my app? Does the operating system send it out on every outbound http request to every single website?
The server (IIS) will indicate to the client (browser) that it needs to authenticate by returning an HTTP 401 error code with a WWW-Authenticate header. The client detects this and determines if it can correctly authenticate. The way this works is as follows:
Determine who the requestor is by checking it's Service Principal Name. It exists as {type}/{fully.qualified.domain}, e.g. HTTP/resource.domain.com. This SPN is mapped to a machine or service account in AD. If this SPN isn't registered, the client falls back to a lesser protocol like NTLM.
Local machine uses the TGT to request a service ticket from AD. AD validates the TGT and looks up the SPN in the request and if found creates a service ticket encrypted against the password of the account associated to the SPN.
Client sends the service ticket to the server via Authorization: Negotiate YII... header.
Server decrypts the service ticket using the password it's been provided, either through a domain join, Windows Service Run As config, or keytab.
Server transforms the contents of the decrypted service ticket into a Windows identity.
Identity is presented to the application.
This flow isn't inherently web-specific. This is how all services authenticate themselves when using Kerberos.
I have a scenario where I have to let external systems have access to one of our internal API's.
The security team want the externals to use client certificates as the preferred authentication method, so that basically leaves us two options:
Use direct client certificate authentication. It will give us the most control, but that will leave all the certificate handling and validation in our hands, and I'd rather not do that if I have a choice. Besides - direct client certification auth does not play well with our existing authentication methods on that API. If you turn on client certificates on the App Service, you will require a certificate on every request (and most requests on that API use cookies)
Add key credentials to the Azure AD app. We'd rather not give access directly to the app the API is registered on, so we register a OUR-APP-EXTERNAL and set up a trust relationship between the two. So the client authenticates with a certificate to the "external app", gets a bearer token and use that on our API. I'd prefer to use this solution, and it seems to play nicely with everything else.
So far so good - but I'm worrying about scaling this. We have to separate the external clients somehow (each client will in effect be different systems in different companies). One strategy is to create one AD-app per external system (OUR-APP-EXTERNAL-SYSTEM-A), but it seems cumbersome and somewhat spammy. One quick and easy solution would be to add some metadata from the client's authentication certificate (where we could just set what system this cert is issued to during creation), and add that to the bearer token.
Is this possible? Or are there other ways to handle "multi tenant" external clients?
Thanks
Consider an option of using Azure API Management for your scenario. API Management provides the capability to secure access to APIs (i.e., client to API Management) using client certificates. Currently, you can check the thumbprint of a client certificate against a desired value. You can also check the thumbprint against existing certificates uploaded to API Management.
Follow this guide - How to secure APIs using client certificate authentication in API Management
Also you can create multiple Azure AD Application for different clients and provide provide required roles to each of these Azure AD application to Azure AD Application registered to secure Internal API.
Follow this guide for this approach - Protect an API by using OAuth 2.0 with Azure Active Directory and API Management
I have a REST api that I would like to secure so only my selected devices (which are embedded) can access the information. I don't want the users to have to login with their credentials; I just need the rest service to only be available for my specific set of devices.
How can I secure the WS to achieve this level of security?
Set up an X.509 certificate authority (CA).
Issue certificates to your devices.
Make your service only available with SSL and client certificates from your CA.
(This is not trivial.)
We have a backend server that services a multi-platform app that will be launched on iOS, Windows 8, Windows Phone 8 and Android. We'd like to use in production as few certificates as possible (preferably just one) to attain the following purposes:
secure communication (HTTPS) with the client application
authentication to the Windows Phone Push Notifications Service
authentication to the Apple Push Notifications Service
Besides taking care that the certificate is issued by a common trusted root authority, are there any other impediments that could prevent a single certificate from being used simultaneously for all these? Is it a viable possibility or is it instead necessary to resort to one certificate for each of the above purposes?
Gabriel I guess there is a problem. Main one is that HTTPS certificate private key cannot be coded by a secret this kind of certificate contain *.crt and *.key file which are not secured. When You want authenticate yourself or server in some Service for example Windows phone push like you have listed there is need to create hash for your private key with secret aka pin or password. What make You use at least two different certificates.
Second thing is that purpose of using certificates is to validate the issuer and to authenticate user/service provider. HTTPS ssl certificate issued by a trusted CA show to the user Hey this is trusted website You should not be afraid passing sensitive data through the service, and the certificates which are used to authenticate are just saying Hey its me I am authorized to use this application Purpose of those certificates and different so certificates them self should be different. Using the same cert for actions like You have listed cause necessaries vulnerabilities and is highly NOT RECOMMENDED