I have a bot service which integrates with Teams. All the interactions will happen via Teams. Their access to Teams serves as their authentication into our system.
The question is whether I should use the Teams ID or the Azure Active Directory (AAD) Object ID as the unique identifier for that user. What are the pros/cons of each? What are other considerations I should factor in. Is either of them more likely to change? What am I not considering that I should be considering?
In simple terms, either one is fine as long as it uniquely identifies the user, and both are "Ids" so they do that. However, the one is purely from a bot perspective, and so it's not even Teams-wide. For instance, if you add a tab to your app later, you'll only get the user's AAD Id, and that's presuming you don't -ever- want to do anything more broadly. So I'd strongly suggest, given the option, to rather use the AAD Id.
Azure Active Directory (AAD) Object ID is the best way to uniquely identify the user.
Also Multiple Teams can contains same users, so if you need a requirement where you want to uniquely identity the user's in different Teams, you can use a custom combination of (Team Id + AAD Object Id).
Related
I have written an Ms Teams Bot using the Bot Framework with .Net and I would like to identify the Owner of the Team in which the Bot is installed (e.g. to send them an adaptive card with more privileged features on it, rather than having the whole team see it).
the V4.9 release note of the bot framework states:
The TeamsChannelAccount object has been updated to include userRole (one of owner, member, or guest) and tenantId (for the user's tenantId)
Yet this seems to be incorrect. When using TeamsInfo.GetMemberAsync or TeamsInfo.GetPagedMembersAsync to retrieve member info (which all return the TeamsChannelAccount object mentioned above) the UserRole property only ever shows "user" as the value - never "owner" or otherwise.
How can I identify the owner of the team? Thank you.
You could instead try to use MSGraph APIs to identify the Owner of a Group. Assuming you have the requisite permissions, you can make a GET call to the appropriate Graph endpoint and it will return to you the owner's ID and name, among other things. You could then use the ID to identify the owner in Teams. MSGraph API calls for getting members also have a roles field, and that can have owner in it as well.
If this solution could work for you, the Teams Auth sample is a good place to start.
Here are some potentially helpful docs pages as well:
List owners
M365 Groups and Teams
Cannot find anywhere on Google Identity Platform docs that clearly describe whether it's possible to assign a single user to multiple tenants. see https://cloud.google.com/identity-platform/docs/multi-tenancy-managing-tenants
My project needs the capability to have a single user be able to login to multiple, separate tenants. Currently, I have to create a new user on every tenant I want to be able to login to. This is not good because each new user I create has a different uid and separate password management. For a single user, I want to be able to maintain the same uid across tenants so the associated user data can be consistent as well.
I was thinking there would be some way to create a user at the project level (not tenant level) and then assign that user to specific tenants?
Some random thoughts: The docs say some things about migrating users between tenants, perhaps that is one way. Also was thinking that creating a tenant user with my existing project-level uid would somehow merge them so the uid and password management is the same?
Edit: I found this conceptual discussion to be helpful: https://softwareengineering.stackexchange.com/questions/403274/multitenancy-with-cross-tenant-users
what I gathered from that link is that SSO is separate from multi-tenancy. So I'm trying to figure out an SSO solution on top of multi-tenancy google idp. Any code solutions/suggestions for how to add SSO on top of multi-tenant google identity platform?
If you need the same user across tenants maybe you should instead rely on the user email, custom claims, federated ID (eg. user.providerData[0].uid). When you get an ID token for the user you have access to this same information regardless of the tenant or user.uid.
As per Google Assistant documentation for Smart Home, the agentUserId used in action.devices.QUERY is defined to 'Reflects the unique (and immutable) user ID on the agent's platform. The string is opaque to Google, so if there's an immutable form vs a mutable form on the agent side, use the immutable form (e.g. an account number rather than email)'
However there can be cases where the same device (with same agent user id) is attached to multiple Google Assistant accounts and in such cases a DISCONNECT request may result is ceasing report state for all accounts. The solution will be to add some unique ID corresponding to the Google Assistant account, however such information is not available in any request.
Has anyone seen similar issue and is my understanding incorrect?
The agentUserId is meant to be the user account on the smart home platform. SHP user '1234' may have a vacuum and two lights, but could be linked to multiple Google accounts.
During the account linking process, you would be expected to give a refresh and access tokens to allow for Google to have authorized control over these devices. If you assign unique access tokens for each Google account that signs in, you'd be able to determine which Google account the request is coming from.
At that point, once the user disconnects, you can use the access token in the request header to associate that with a specific Google account and only disable reporting for that account while not affecting other accounts.
So, yes the solution is to have a unique ID connecting to the account. While this is not passed in the agent ID, there is already a mechanism to make this association through the authorization system.
Alternatively, you could append a key in the agentUserId, ie. '1234-user#gmail.com'. However, this may have unintended impacts in the Home Graph. In a multi-user home, you may end up seeing the devices duplicated because Google doesn't have the right information to deduplicate.
I have a custom application for internal use only where currently users are created by a super admin. Some of the users are from within the business and some external e.g. suppliers/customers.
I'm looking for a way to integrate MS Active Directory as a login option but want to be able to restrict which users from the business can actually use this method.
I have search through all the MS docs and have all the documentation on the different oauth approaches but not sure which one would be suitable for my needs.
I am thinking that perhaps i need to give the admin a way to browse the AD and select the users that can login which then creates inactive user accounts in the mysql database with some sort of MS user ID. Then provide a 'Sign in with MS' button that does the usual auth redirection process to MS and back to the site. At that point I can check an ID and if that matches an allowed user account and if so, sync the rest of the data e.g. name, email, phone etc..
Links I've already found:
https://learn.microsoft.com/en-gb/azure/active-directory/develop/authentication-scenarios
https://learn.microsoft.com/en-gb/graph/tutorials/php
https://github.com/microsoftgraph/msgraph-training-phpapp/tree/master/Demos/03-add-msgraph
Your first order of business is enabling a user to sign in to the Laravel-based app. For this, I strongly recommend not trying to re-invent the wheel (at least not completely), and make use of an existing Laravel package. Laravel Socialite is probably the best place to start, since it has a long list of existing community-provided Socialite providers, including three which work with Azure AD already: Microsoft, Microsoft-Graph and Microsoft-Azure. (Note: Though I haven't tested any of these myself, the first two seem to be the most promising, as they use the newer v2 endpoint.)
When it comes to authorization (controlling access), you have two options:
Control at Azure AD
Once you've got the app integrated with Azure AD, you can configure the app in Azure AD to require user assignment, and then control access to the app by assigning (or not) users to the app. Users who are not assigned won't even make it past the sign-in page.
You can use Azure AD's existing experiences for managing user and role assignment for the app, or you could go all-out and build this experience directly into the Laravel-based app itself, making use of the Azure AD Graph API to create the [app role assignments](https://learn.microsoft.com/en-us/previous-versions/azure/ad/graph/api/entity-and-complex-type-reference#approleassignment-entity and user picker experience.
Hint: In either case, remember that you can make the app "superuser" an "owner" of the app in Azure AD (Azure AD > Enterprise apps > (app) > Owners), which will allow them to assign users without needing to give them any additional privileges in Azure AD.
Control at the app
In this approach, you allow all users to sign in to the app with Azure AD, but then you use your app's own authorization logic to decide who makes it any further, and what roles they get in the app.
In reality, you will most likely find the best approach is to use a combination of the two, with some of the authorization enforced by Azure AD and the next level enforced by the app itself.
If you would do it in this way, it will be necessary that the super-admin has always this permissions in the AAD. From my point of view it is less practical.
I would perfer such app-assigments with help of Service Principal. You assign a role (look for app roles) to the user and then your business logic must decide which permissions the user has. If you would use the app roles feature, then you can restrict access to the role with it's help. All the user can login, but only users with a specific role would be able to see a content of the app.
I hope this hints can help to find a right direction, but there is no silver bullet solution... :/
We are trying to integrate our platform with Pipedrive. As far as we have researched, in a pipedrive account, there is one admin and he can add multiple users. And the users later can login in their respective accounts.
What we are trying to make sure is that once a Pipedrive account is integrated with our platform, the same account should not be integrated twice. So, I need a unique identifier, that lets me know whether the account has already been integrated.
My initial approach was to check the api key. But it was not successful, since every users in an account have different API Keys.
After a bit of research, I found out that there is an identifier called company_id which is common for all the users in an account. But I could not find anything regarding it in documentation. So, I am not 100% confident to go ahead and implement it in our code.
Does anyone have an idea about this?
Pipedrive support rep here.
The most sure-fire way to ensure this is to make a GET request against http://api.pipedrive.com/v1/users?api_token=your_token_here.
You are correct in assuming the company_id in the additional_data object in the response is static and won't change across any users on the account.
Note that a Pipedrive account may have more than one admin, and that non-admins (regular users) might have visibility (and editing) restrictions in place, which may cause some of your GET, PUT and DELETE requests to fail.
In case you're not doing this already, I'd thus advise filtering the data array from the abovementioned endpoint for user.is_you to equal true and check whether the is_admin property is set to 1 during "registration" to ensure the user setting up the integration is an admin.
Hope this helps!
I'm not quite sure what you're asking for. Are you looking for a unique identifier for each user?
Each user has an id, you can get all users by calling
https://api.pipedrive.com/v1/users?api_token=____
This will return a JSON Object with data on your users, including their names and associated IDs. Admins are just users with different privilege levels. All admins are users, but not all users are admins. All users are part of a company, the company is identified by the first part of the Pipedrive account url ie.
https://FooCompany.pipedrive.com
Are you trying to see if a certain company has been integrated already?