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.
Related
In my project, there is a mobile app, an angular web app, 4 micro services and one api gateway. The users with role 'agent' can enroll customers using the mobile app. The web app is for users with role 'manager' to see the customer data and finalize on the customer enrollment.
Here, if I want to set up Keycloak for authentication, should I add
every micro service as a separate client ?
Should I add mobile app and web app as separate clients in keycloak ?
CLIENTS
The web and mobile app must be registered as separate OAuth clients. They will have a client ID but no client secret since they are public clients. They will use PKCE and have different redirect URIs, eg:
Web: https://www.example.com/callback
Mobile: com.example.app:/callback
APIs
By default APIs do not need to be registered as clients. In most setups related microservices can just forward JWT access tokens to each other, as explained in the scopes article. This is a secure way to maintain the user identity.
APIs sometimes act as clients though, eg if they need to do something like create users in Keycloak programmatically. Identity systems provide User Management Endpoints to enable this.
So one of your APIs, eg a Users Microservice, may need to be registered as a client. It would use the client credentials flow to get an access token with a SCIM related scope.
GATEWAY
It is common, and recommended, for a gateway to act as an introspection client. This enables data in access tokens returned to internet clients to be kept confidential. Read more about this in the phantom token pattern.
I'm trying to figure out how to migrate a system that is currently using ACS to Azure AD. I've read the migration docs provided by Azure and have looked through the Azure AD docs and the sample code but I'm still a bit lost as to what the best approach for my situation would be.
I've got a web API that has about 100 separate external systems that connect to it on a regular basis. We add a new connections approximately once a week. These external systems are not users--these are applications that are integrated with my application via my web API.
Currently each external system has an ACS service identity / password which they use to obtain a token which we then use to authenticate. Obviously this system is going away as of November 7.
All of the Azure AD documentation I've read so far indicates that, when I migrate, I should set up each of my existing clients as an "application registration" in Azure AD. The upshot of this is that each client, instead of connecting to me using a username and password, will have to connect using an application ID (which is always a GUID), an encrypted password, and a "resource" which seems to be the same as an audience URL from what I can see. This in itself is cumbersome but not that bad.
Then, implementing the authorization piece in my web API is deceptively simple. It looks like, fundamentally, all I need to do is include the properly configured [Authorize] attribute in my ApiController. But the trick is in getting it to be properly configured.
From what I can see in all the examples out there, I need to hard-code the unique Audience URL for every single client that might possibly connect to my API into my startup code somewhere, and that really does not seem reasonable to me so I can only assume that I must be missing something. Do I really need to recompile my code and do a new deployment every time a new external system wants to connect to my API?
Can anyone out there provide a bit of guidance?
Thanks.
You have misunderstood how the audience URI works.
It is not your client's URI, it is your API's URI.
When the clients request a token using Client Credentials flow (client id + secret), they all must use your API's App ID URI as the resource.
That will then be the audience in the token.
Your API only needs to check the token contains its App ID URI as the audience.
Though I want to also mention that if you want to do this a step better, you should define at least one application permission in your API's manifest. You can check my article on adding permissions.
Then your API should also check that the access token contains something like:
"roles": [
"your-permission-value"
]
It makes the security a bit better since any client app with an id + secret can get an access token for any API in that Azure AD tenant.
But with application permissions, you can require that a permission must be explicitly assigned for a client to be able to call your API.
It would make the migration a tad more cumbersome of course, since you'd have to require this app permission + grant it to all of the clients.
All of that can be automated with PowerShell though.
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.
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.
I'm in the process of rearranging our web-based systems, so that users will be able to log on to our systems through a Sharepoint front-end. Our single sign-on server is an Oracle SSO server that authenticates against the same domain as the sharepoint server does, but these two are currently 2 separate logins.
What I'm looking for is to configure this scenario:
A user logs in to the Sharepoint site, authenticating agains Active Directory through the TMG. This gives the user access to the sharepoint site, and this is all standard OOTB functionality. Then the user should be able to navigate into our other systems without a re-login (because the SSO configured for external authentication with the same AD, and therefore uses the same userbase).
So basically the users currently have to login twice with the same domain\user + password. I would like the SSO server to be able to read the cookie that was established in the first login, and use that instead of presenting the SSO login screen all over again.
Is it possible to share such a cookie between 2 different platforms on the same domain?
I have implemented a kerberos "Zero-sign-on" approach for the Oracle SSO server, but this only works as long as the user comes from a computer inside our domain. When the user logs on from the outside world (www) he will be prompted to login to sharepoint first, and then to the Oracle SSO.
I basically need the Oracle SSO Cookie to somehow read the Sharepoint Cookie that was established. Does this make sense?