There are two methods for authentication listed in the REST API documentation: https://learn.microsoft.com/en-us/azure/cognitive-services/openai/reference
I see that an Azure policy (https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Cognitive%20Services/CognitiveServices_DisableLocalAuth_Audit.json) supports disabling local authentication for the type “Microsoft.CognitiveServices/accounts”.
I would only like people to use Azure Active Directory authentication. Would I be able to ensure this (AAD) is the only option used with the built-in policy?
Related
I have been working with the Android Management API to try and manage the policy of my company's existing enterprise. My company account has the Owner role within the organization and the roles Owner and Service Account Admin for the service account mentioned later.
I followed the Quickstart Guide to get familiar with the API and made some modifications for a more permanent solution along the way such as creating a service account with the Android Management User role via the Google Cloud Platform and generating a JSON key to acquire credentials rather than going through the OAuth2 flow like in the guide. This allowed me to authenticate properly, but when it comes time to patch the policy as such,
androidmanagement.enterprises().policies().patch(
name=policy_name,
body=policy_json
).execute()
I get the following error:
<HttpError 403 when requesting https://androidmanagement.googleapis.com/v1/enterprises/XXXXXXXXX/policies/<policy_name>?alt=json returned "Caller is not authorized to manage enterprise.". Details: "Caller is not authorized to manage enterprise.">
I have verified that the service account I am authenticating with has the Android Management User role, and thus has the androidmanagement.enterprises.manage permission.
I have also attempted to make this call with an elevated admin role in the organization.
Is there a chance that I need to have created the enterprise with my own account to manage the enterprise? The guide suggests that an organization can create multiple enterprises. In which case, would I need to create a new Google account not associated with my organization's enterprise and create a new enterprise that way?
It is advisable to use your own google account to call Android Management API since your organization account may not be compatible with the quickstart.
To access the Android Management API your service account requires the androidmanagement.enterprises.manage permission, which can be granted by the Android Management User role (or roles/androidmanagement.user). Kindly check this link for details regarding creating a service account.
Please keep in mind that the enterprise you created as part of the colab instructions can only be managed using the colab itself. To allow your cloud project to manage an organization, you will need to create one using the client configuration from your cloud project.
Is it possible to use Azure AD B2C authentication in a localhost Azure Functions project? If yes, how can this be done?
There are examples of using Azure AD B2C authentication for local ASP.NET Core projects, but I have not seen any examples for local functions projects.
As Azure Function is designed to run a small spice of code. You can not add AAD authentication to it as you do to an ASP.NET project directly.
Some ideas:
For cloud environment, you can integrate AAD authentication from Azure portal. Here is a tutorial: ADDING AZURE AD B2C AUTHENTICATION TO AZURE FUNCTIONS
You can always manually get the authentication header from a http request. And then manually verify the token you get to see if it is authenticated.
Microsoft will end support for basic authentication in Exchange Online remote powershell October 13th, 2020.
Server-to-server communication can be done using the System.Management.Automation.Runspaces.WSManConnectionInfo class with basic authentication. What is the supported way for an on-premise daemon application to run remote powershell in Exchange Online when basic authentication is no longer supported?
If you don't want to rewrite your remote PowerShell code to use the new V2 Exchange Online Management module shown by #stukey above, you can use an alternative workaround by using ADAL (or a similar library) to fetch an access token from AzureAD, then use the token as password when constructing your PSCredential.
If you add ?BasicAuthToOAuthConversion=true to the connection URI, the server will then pull the token from the basic auth header and use modern authentication with the token instead.
The workaround is outlined here and semi-documented by Microsoft here.
Assuming your daemon application is using a Service Account ID without MFA, then you can utilise the new V2 Exchange Online Management PowerShell module to connect to EXO using Modern Auth. It handles everything for you, so you can still initiate a connection using your Service Account username and password credentials, and the module will use those creds to get a token from Azure AD and then authenticate to EXO using Modern Auth. Works great if your Service Account creds are managed by a separate password vault solution. If you can’t use credentials-based auth, then Microsoft are working on an update to the EXO module that will allow you to authenticate to EXO using a registered Azure AD app together with certificate-based auth. That should be coming soon...
Our current API use seesionID for the authentication. We plan to use Azure API management to manage our web api. However Azure web api management has their own authentication. How can we link those two together. Our customer can use the same logon information.
Conversations about authentication and identity in Azure API Management can get tricky because there can be three different identities and then there are the different contexts of runtime requests vs management requests. So, to be sure I'm answering the right question, let me try and get some terms defined.
The three identities:
API Provider: This is the Azure user who has created an API Management instance.
API Consumer: This is a developer who is writing some client software to consume the API.
End User: The user of the application written by the API Consumer and will be the one who actually initiates runtime requests to the API.
I am assuming that you are the API Provider. What I'm not sure about is whether your customers are the API Consumers or the End Users.
Azure API Management provides identity services for API Consumers. Consumers can either manually create a username/password account or use some social identity provider to create an account. They then can get a subscription key that will allow Azure API Management to associate requests to the API Consumer.
I think you are asking if you can connect the sessionID, which I am guessing you use to identify End Users, to a subscription key used to identify API Consumers. If that is correct, then the answer is no (except for the scenario described below), because we need to identify the API Consumer key before any policies are run to ensure we run the correct policies.
You can change our Api Consumer subscription key. So, if you only have a low quantity of customers/End Users you could create an Api Consumer account for each End User. However, you would only be able to map sessionID to API Consumer Subscription Key if sessionID was a constant value. I'm presuming based on the name, that value changes at each login.
Although Azure API Management provides identity services of API Consumers, it does not provide full identity management for End Users. We leave that to external partners like Azure AD, Thinktecture Identity Server and Auth0. I'm assuming that your existing system is already using some kind of identity provider to generate the sessionId. What you can do with Azure API Management is validate that sessionId using policies in the API Management Gateway. To do that we would need to know more about the format of the sessionId.
Sorry for the long post but it is a confusing topic and I wanted to be as clear as possible.
Amazon Cognito supports OPENID auth and OATH. Is it possible to use LDAP instead to authenticate the user?
You can support any authentication system with Cognito, but you will need to use a slightly different authentication flow than existing public providers. Instead of calling Cognito directly from the device you will need to construct your own backend that will handle the authentication then call Cognito to establish the trust of your identity.
Please see the following for more details:
Amazon Cognito : Announcing Developer Authenticated Identities
Understanding Amazon Cognito Authentication Part 2: Developer Authenticated Identities