Overview
For some companies, access to Office 365 / Microsoft Teams resources is restricted. If you can’t login from Jira or Microsoft Teams, your Office 365 administrator might need to consent to the app for you.
In case you are interested in the exact permissions and why we need them, please check out this dedicated permissions article.
Technical identifiers
Below you can find a list of necessary client ids and scopes. The following base scopes are required for all features:
email offline_access profile openid
App feature | Client Id | Mandatory scopes |
---|---|---|
| Mail.ReadWrite.Shared Mail.Send.Shared People.Read User.Read User.ReadBasic.All | |
Meetings |
| Calendars.ReadWrite.Shared OnlineMeetings.ReadWrite User.Read User.ReadBasic.All |
Calendar |
| Calendars.ReadWrite Calendars.ReadWrite.Shared OnlineMeetings.ReadWrite People.Read User.ReadBasic.All OPTIONAL Place.Read.All Group.ReadWrite.All Team.ReadBasic.All |
To Do |
| Tasks.Read Tasks.ReadWrite Tasks.ReadWrite.Shared User.Read |
Teams |
| |
Teams JSM portal |
|
Approving access for all users
To approve access for the app for all users, please send your Office 365 administrator the following link.
--- Short link https://go.yasoon.com/products/tfj/teams-admin-consent
Your admin will see the following screen, where the permissions can be confirmed. Please note, that despite what the screen says in the subtext, we won’t get access to all user resources after approving this. Before we can get access to any Microsoft Teams data, the users will need to log in with their own account as well from Jira.
Approving access for a limited set of users
In case you only want to approve the access for a limited set of users, e.g. you already have a dedicated AzureAD group for Jira users, please follow the steps below.
Usually, when approving the app for the first time, it’ll create a “service principal / enterprise application” in your AzureAD tenant. You can check if you already have an enterprise app by checking this page (search for Teams):
https://portal.azure.com/#blade/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/AllApps/menuId/
# Install Microsoft Graph Powershell toolkit Install-Module Microsoft.Graph -Scope CurrentUser # The app for which consent is being granted. In this example, we're granting access # to Microsoft Graph Explorer, an application published by Microsoft. $clientAppId = "8c32a034-6431-465a-81fa-74823a7d4226" # Microsoft Graph Explorer # The permissions to grant. Here we're including "openid", "profile", "User.Read" # and "offline_access" (for basic sign-in), as well as "User.ReadBasic.All" (for # reading other users' basic profile). $permissions = @("openid", "profile", "offline_access", "User.Read", "email", "TeamsAppInstallation.ReadWriteSelfForChat") # Step 0. Connect to Microsoft Graph PowerShell. We need User.ReadBasic.All to get # users' IDs, Application.ReadWrite.All to list and create service principals, # DelegatedPermissionGrant.ReadWrite.All to create delegated permission grants, # and AppRoleAssignment.ReadWrite.All to assign an app role. # Group.Read.All is necessary if you want to use users from a security group Connect-MgGraph -Scopes ("User.ReadBasic.All Application.ReadWrite.All " ` + "DelegatedPermissionGrant.ReadWrite.All " ` + "AppRoleAssignment.ReadWrite.All " ` + "Group.Read.All") # Step 1. Check if a service principal exists for the client application. # If one does not exist, create it. $clientSp = Get-MgServicePrincipal -Filter "appId eq '$($clientAppId)'" if (-not $clientSp) { $clientSp = New-MgServicePrincipal -AppId $clientAppId } Write-Host "Service principal for $($clientAppId) is $($clientSp.Id)" # Step 2. Define users that should have the app consented # Either use a single, hard coded user (upn or GUID) $userIds = @(Get-MgUser -UserId "miriamg@yasoondemo.onmicrosoft.com") # Or assign app based on a security group # $userIds = Get-MgGroupMember -GroupId '<groupGuid>' -All | % {$_.Id } # Loop over selected users foreach ($userId in $userIds) { # Step 3. Create a delegated permission that grants the client app access to the # API, on behalf of the user. If the existing grant already exist, skip creating it # Note: In case of changed scopes, this is not updated automatically yet $existingGrant = Get-MgOauth2PermissionGrant -Filter "consentType eq 'Principal' and principalId eq $($userId) and clientId eq '$($clientSp.Id)'" if (-not $existingGrant) { $resourceSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'" $scopeToGrant = $permissions -join " " New-MgOauth2PermissionGrant -ResourceId $resourceSp.Id ` -Scope $scopeToGrant ` -ClientId $clientSp.Id ` -ConsentType "Principal" ` -PrincipalId $userId # Step 4. Assign the app to the user. This ensures that the user can sign in if assignment # is required, and ensures that the app shows up under the user's My Apps. # The app role ID 00000000-0000-0000-0000-000000000000 is the default app role # indicating that the app is assigned to the user, but not for any specific # app role. New-MgServicePrincipalAppRoleAssignedTo ` -ServicePrincipalId $clientSp.Id ` -ResourceId $clientSp.Id ` -PrincipalId $userId ` -AppRoleId "00000000-0000-0000-0000-000000000000" } }
If you don’t have an entry for our Teams app yet, you’ll need to use Powershell to create it manually.
# Install Powershell module for Azure (if you don't have it yet) Install-Module AzureAD # Connect to Azure interactively Connect-AzureAD -Confirm # Create the new service principal New-AzureADServicePrincipal -AppId 89d5ca9f-d63b-4885-bd30-6e7433c1540c -Tags {WindowsAzureActiveDirectoryIntegratedApp}
Afterwards, you should be able to find the enterprise app in the UI linked above, where you can restrict the application to certain users or groups, or, using the “Properties” page, allow users to self-approve the app: