Is there other ways of authorizing against the Azure Service Bus using AMQP than username and password such as tokens from the ACS?
In my scenario I want to be able to give resource level client access to the service bus without exposing my credentials.
Today, in the preview release of AMQP support in Service Bus, the SASL username/password scheme is the only authentication option.
It is still possible to provide resource-level client access with this model though as you're free to create multiple identities within ACS and associate a limited set of claims with those identities. In fact, this is recommended best practice. The alternative of using the default namespace 'owner' identity in a production set up is analogous to giving application components access to the root password.
So, my recommendation would be to create ACS identities for each "role" in your application and then grant only the claims required by that role. For example, if a Web tier component requires the ability to send to a queue, q1, then create an ACS identity for this Web tier role and grant the 'Send' claim to that identity.
Thanks,
Dave.
Service Bus Team, Microsoft.
Related
We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).
Is there a way to do that?
That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.
Most commonly:
The AS might be hosted in the cloud
It will redirect browsers to an on premise Identity Provider (IDP)
The IDP can connect to Active Directory
You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.
If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.
Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.
REQUEST FLOW
Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:
Your apps will make a standard OpenID Connect authorization redirect to the AS
The AS may then present an authentication selection screen to the user, unless there is only a single option
Alternatively an app can send the acr_values query parameter to say which authentication method to use
The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket
I want to create Microsoft Teams search messaging extension with OAuth.
The problem is, our customers host their servers, and because of that, they have different Authentication servers.
For example there is 2 company, Company1 and Company2, and they have 2 servers, company1.com and company2.com, and they have 2 Authentication server (company1.com/auth and company2/auth).
And if a user from Company1 wants to use the messaging extension, the user wants to log in with the company1.com/auth Authentication server.
Is there a solution (what works with 1000+ customer), where every customer can use their own Authentication server to log in? (Without manipulation OAuth Connection Settings in the Bot Channel Registration)
I'm not sure I fully understand the scenario, and I'm also not an auth expert, but perhaps this will help: You could register multiple OAuth connection entries with the bot, inside the Azure portal (i.e. one for Company 1 and one for Company 2). Next, inside your bot, when the message extension is invoked, it passes along the tenant id of the user who invoked it, and you could use this to perform a lookup against which OAuth connection to use.
I am trying to create jmeter script for login in to iphone native app. App is using cognito to authenticate the user.
As response of first page of app I am getting SALT and Secret block.
I am passing this secret block in and other required parameters in next request, however I got error message as "User name or password is in correct".
Did anyone worked successfully on similar things which can help me.
Looking into Amazon Cognito page:
Social and enterprise identity federation
With Amazon Cognito, your users can sign in through social identity providers such as Google, Facebook, and Amazon, and through enterprise identity providers such as Microsoft Active Directory via SAML.
Standards-based authentication
Amazon Cognito User Pools is a standards-based Identity Provider and supports identity and access management standards, such as Oauth 2.0, SAML 2.0, and OpenID Connect.
You will not be able to record and replay none of the mentioned protocols, depending on underlying identity provider mechanism you will either need to apply advanced correlation or a way to provide the required Bearer Token.
So you need to identify which identity mechanism is used under the hood and amend your JMeter test accordingly.
Reference material:
How to Load Test SAML SSO Secured Websites with JMeter
OpenID Connect - How to Load Test with JMeter
How to Run Performance Tests on OAuth Secured Apps with JMeter
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.
We are trying to put an app on the marketplace which needs multiple client_ids
(The app is running on appengine standard with python 2.7)
a client_id for the service_account with domain wide authority
a client_id for the web application
a client_id from an apps-script library
All client_ids use different scopes. I have combined all scopes and entered them on the marketplace SDK configuration.
When i deploy the app on a test domain, only the serviceaccount seems to be authorized.
When the user then access the webapplication he is presented a grant screen which we want to avoid.
The documentation https://developers.google.com/apps-marketplace/preparing?hl=fr seems to imply that multiple client_id's are possible.
How should i configure the marketplace app so that multiple client_ids are authorized?
Is there something special i should do on the credentials configuration page of the api-manager?
Check how you implement the authorization using OAuth 2.0, Service accounts allow a Google Apps domain administrators to grant service accounts domain-wide authority to access user data on behalf of users in the domain. You can also read Server to Server Applications documentation.
Note: You can only use AppAssertionCredentials credential objects in applications that are running on Google App Engine or Google Compute Engine. If you need to run your application in other environments—for example, to test your application locally—you must detect this situation and use a different credential mechanism (see Other). You can use the application default credentials to simplify this process.
Hope this helps.
It turned out all three client_id's were being authorized after all.
the days that i was testing this, it took very long for the authorization to take effect.
At this time all scopes and clientid are authorized within a few minutes.