We have a solution that uses Certificate-based Authentication with Azure Service Principals on Windows. It's documented in the following article:'
Building Daemon or Service Apps with Office 365 Mail, Calendar, and Contacts APIs (OAuth2 client credential flow)
https://blogs.msdn.microsoft.com/exchangedev/2015/01/21/building-daemon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow/
We need a solution similar to the one above that will work on Linux Servers.
The below WIKI by the Azure Identity SDK team has the conceptual documentation here:
https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/Client-credential-flows
The dotnet core sample:
https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-certificate-credential
works on Linux however the part of the sample generating the cert will not work as powershell on Linux is based on .net core which doesn't yet support the cert modules required.
Related
Due to security policy, connecting to AWS programmatically with PowerShell using an Access/Secret Key is not allowed at our organization anymore, and needs to be replaced with AWS SSO. But I didn't find any clear documentation on how to actually connect to AWS with PowerShell, using AWS SSO. On AWS official documentation for PowerShell Cmdlets, I can see a cmdlet named: Close-SSOSession, which is very straight forward about what is does. but which cmdlet is used to open the session in the first place? I would expect something like: Open-SSOSession. I also need to mention, that we are not allowed to install AWS CLI V2 on our Windows servers, as only the AWS PowerShell Module is approved to use by developers.
As I am a programmer with solely experience with production environments in the cloud that run with a cloud-based secret manager, I was wondering: How are secrets managed in an on-premise instance? I bet they are not just written in the application settings or the OS environment variables?
• There is no equivalent of azure key vault in on premises environment though you can use ADCS (Active directory certificate services) for certificate shared secret management in on premises infrastructure for authorizing and authenticating resources, service principal names and other identity attributes.
• Though for the handling of the cryptographic keys used by the cloud apps and services hosted on premises, we can setup app key vaults for business central on-premises server as well. Please refer the below official documentation for your reference: -
https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/setup-app-key-vault-onprem
This document articulates the steps and processes to undertake for integrating the functionality of Azure key vault in your on-premises environment.
• Though, if you want to directly use the Azure key vault’s functionality in your on-premises infrastructure environment, you can provide internet access to your on-premises resources and use client certificate authentication and IP restrictions with key vault through a VPN tunnel for additional security.
Please refer the below links for more information: -
secret management in on premise application
I have a web application running in a docker container. I need to let only the users authenticated with Microsoft SSO (only the users in my AzureAD tenant). The web application is written in Spark Java and trying to change the existing basic authentication to Azure with MSAL4j is proving to be time consuming and difficult.
Is there a way to authenticate all users with SSO externally to the container without having to change my application?
I saw an Azure NGINX solution on NGINX site but it seemed to not have a free version. Anything I can use out of the box or develop?
TIA!
There is no way to authenticate all users with SSO externally to the container without having to change your application. You would need to change your application code and add the Azure Authentication manually.
we have the following situation. A Open Source Cloud Foundry installation and an independent Gitlab installation. I would like to use the Gitlab Token to identify User in the CF UAA, means everybody registered at the Gitlab is able to use CF.
Is there a possibility to combine this two system?
This is currently not supported by UAA.
We have plans to add supports for Generic OAuth 2.0 based external identity providers in the future.
We want to migrate our custom steps from XAML build to new build task in TFS2015 on-premise. I installed NodeJS and tfx-cli but when tfx-cli want to connect to TFS I need to provide pat (personal access token) but I cannot find where I can get it. All samples is for VSO but not for on-premise TFS2015. Is it possible to get PAT from on-premise TFS2015?
TFS 2015 doesn't support Personal Access Tokens, this feature was introduced with TFS 2017. In the mean time you'll either need to configure basic auth and use that (only enable basic auth if your TFS server is running over SSL), Or use the trick below to trick the command lien tools to authenticate by lettign an NTLM proxy (like Fiddler) handle the auth for you.
If you do not want to configure Basic Authentication on your TFS server (which many people don't want due to security concerns), then you can use a neat trick to let Fiddler handle your authentication:
Then enter:
C:\>set http_proxy=http://localhost:8888
C:\>tfx login --auth-type basic --service-url http://jessehouwing:8080/tfs/DefaultCollection
You'll be prompted for a username and a password, it doesn't really matter what you enter, fiddler will handle the authentication for you in the background:
More detailed steps outlined on my blog.
If you're battling self-signed certificates, which is also a common problem when using tfx against a on-premise TFS server, make sure you're using a recent enough version of Node and point it to an aditional cert store using environment variables:
As of Node.js 7.3.0 (and the LTS versions 6.10.0 and 4.8.0) it is now possible to add extra well-known certificates to Node.js with an environment variable. This can be useful in cloud or other deployment environments to add trusted certificates as a matter of policy (as opposed to explicit coding), or on personal machines, for example, to add the CAs for proxy servers.
See the CLI documentation for more information on using NODE_EXTRA_CA_CERTS, as well as the original pull-request.
NODE_EXTRA_CA_CERTS=file#
Added in: v7.3.0
When set, the well known "root" CAs (like VeriSign) will be extended with the extra certificates in file. The file should consist of one or more trusted certificates in PEM format. A message will be emitted (once) with process.emitWarning() if the file is missing or malformed, but any errors are otherwise ignored.
Note that neither the well known nor extra certificates are used when the ca options property is explicitly specified for a TLS or HTTPS client or server.
There's another option for tfx-cli to connect to the TFS instance, and it is basic authentication. Just use the following format:
tfx login --auth-type basic --username myuser --password mypassword --service-url http://tfscollectionurl
Here is the quote from Github:
You can alternatively use basic auth by passing --auth-type basic
(read Configuring Basic Auth). NTLM will come soon.
Note: Using this feature will store your login credentials on disk in
plain text.