Is there a way to turn off location permission in Windows 8.1? I asked this because of a rejection from Windows Store :
App Policies: 10.5.1 Privacy Policy
If your app accesses, collects or transmits personal information, or if otherwise required by law, you must maintain a privacy policy. You must provide users with access to your privacy policy in the Description page of your app (including by submitting it to Microsoft for display to users). In addition, your privacy policy must be accessible from your app at any time. The privacy policy can be hosted within or directly linked from the app. Your privacy policy must inform users of the personal information accessed, collected or transmitted by your app and how that information is used, stored, secured and disclosed. It must describe the controls that users have over the use and sharing of their information and how they may access their information, and it must comply with applicable laws and regulations. Your privacy policy must be kept up-to-date as you add new features and functionality to your app.
Additionally, apps that receive device location must provide settings that allow the user to enable and disable the app's access to and use of location from the Location Service API. For Windows Phone 8 and Windows Phone 8.1 apps, these settings must be provided in-app. For Windows Mobile 10 apps, these settings are provided automatically by Windows within the Settings App (on the Settings->Privacy->Location page).
Thanks
Permissions are granted by the end user, so cannot be revoked, or set programmatically. Instead the first time you call something that requires the permission, the end user will be asked to grant access (they can later revoke this using the Location section in settings)
Related
I have a React Application that uses Microsoft AD to authenticate users.
As a first step, and according to Microsoft Documentation, we need to register the application with the Microsoft identity platform.
This is inline with Microsoft Identity Platform Documentation, in this diagram we can see that for ALL types of applications (SPA, Web App, etc), we always need to configure an application in AzureAD:
This process is "cumbersome", and i'm trying to remove it by having the application installed automatically.
Several third-parties do this, such as Zapier, SpecFlow, etc.
Basically, they have a process where:
User logs in on Zapier
User is redirected to Azure AD sign-in page
User is authenticated and authorized
AzureAD shows the Consent Page
User consents
Application is installed on user's AzureAD
I've been reading and searching in Microsoft's Documentation, and i cannot find a single document that shows or even mentions this type of flow.
BUT, i know that this is possible, as there are several third parties that are doing exactly this, as Zapier, for example.
Can anyone point me in the right direction, there must exist some Microsoft document that explains how this process is done!
Apologies if this should be a comment, not an answer. I do not have enough SO reputation to write comments.
Zapier is published to the Azure Active Directory application gallery (1c76d9b0-0826-4b19-8706-29572657af1e). You can do this as well:
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/v2-howto-app-gallery-listing
If an application already exists in the gallery, it does not need to be "registered" in the user's tenant, as the registration definition is defined in the gallery.
Once an app is in the gallery, users can use it only if their tenant's administrators allow this, per the settings on this page:
Enterprise applications | User settings
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/~/UserSettings
From the user's end, there are other governance controls that may impact the user's ability to use your app, but I think "register your app in the gallery" is probably what you're asking for.
What is delegated in Msgraph api. Does it mean we can't use it by creating app on Azure Active Directory.
https://learn.microsoft.com/en-us/graph/api/application-post-calls?view=graph-rest-1.0&tabs=http#permissions
I want to use online meeting and call apis without my customers to register teams or microsoft
Delegated permissions are used to call APIs on behalf of a signed-in user.
If an API only supports them, a user will have to sign in to your application so that you can call the API on their behalf.
Refresh tokens allow you to do this for a long time without requiring the user to interact with the app, but those can and do expire.
Another choice might be to use the ROPC flow, but that requires you to use a username and password to get tokens, and that user cannot have MFA enabled for example (one of many cases where ROPC does not work).
There are two primary mechanisms that an application can use to access the Graph. The one is an "Application" approach, where it needs to be given access rights by an administrator, and can then access certain services / endpoints. There's often an "app secret" that is used in conjunction with the application "Id". This is kind of similar in the past to how we would have created a specific 'service' account + password. ROPC is even more similar, and actually -does- require a username + password, but it's not generally recommended.
The other is "delegated", which means that the application can access certain resources that are specific to that user (like their own mailbox for example). In this case, the user themselves might be required to 'approve' the application's right to access the graph on his/her behalf.
Note that BOTH of these options involve the use of an Azure AD Application, but which permission option you can use depends on the specific operation in the Graph that you're interested in calling. As an example, let's say you wanted to access the list of members in a Teams team. This is explained here, where the "permissions" section indicates that either Application or Delegated permissions can be used to do this. In contrast, here is another operation that can ONLY be done with Delegated permissions, and not by a standalone application without a user granting access.
My organization is taking a look at the security of registered applications within Azure Active Directory (AAD) and have concerns around the ability of individuals to add client secrets and certificates for applications that are using the "application permissions" model. I'm working to help narrow the roles of individuals within the organization to restrict this, but this investigation begged the question of what a malicious insider could do if he or she could add a client secret to this application.
I've looked through the 30 Days of Microsoft Graph blog series, which is excellent, but wanted to clarify what else can be done to prevent an insider from gaining access to the permissions this application would allow.
Does the redirect URL itself protect against this kind of scenario, provided the organization retains control of all registered URLs (meaning, for example, that https://localhost isn't registered)? Based on this post under Step 3, I assume the answer is yes but wanted to make sure this is the case.
Is it technically correct to say that without the redirect URL being secured/owned by the organization, a malicious insider who could add client secrets could exploit the permissions granted by the application?
If you are able to add a client secret to an app that already has been granted application permissions to something, then this user can use the new secret to get tokens and access those resources as the app.
Redirect URL is not used with application permissions, only delegated permissions.
This is because there are no redirects in the client credentials grant flow, which is used when acquiring a token with app permissions.
It's just an HTTP request.
So you are correct in your assumption that being able to add a new secret to an app that already has permissions can be a security issue.
There are audit logs though, and I believe adding a secret/certificate is logged.
I have successfully configured qn Azure AD App Registration, allowing a client_credentials based OAuth 2.0 flow to work. This allows a third party application to access Microsoft Graph API. The app has "Calendar.Read" permission. Meaning the app can pretty much read any of the calendars (including CEO's).
I now have a conversation with security. What is out there in the Microsoft world, that I can use to lock down usage of API access via this Application Permission? Is there ability to do things like:
Restrict IP ranges the App can be accessed from?
Restrict users that can access the App? (However in Client_credentials, there is no user context)
Log traffic / activity happening via the App?
The only thing i can think of now is to say the Redirect URL configuration on the app means, no other application can get an access token using the Client_credentials, even if the application id & passkey get compromised
Any advice on further security controls that can be put in place?
Restricting access: You would need to do this in your application. The Client Credential flow doesn't allow for restricting what users as you point out. However there is nothing stopping you from adding user authentication to your application, possibly using a delegated graph auth flow to determine who they are.
IP Ranges: This is not possible currently.
Logging Traffic: This is not possible on the graph side currently, however you could/should log traffic on your applications side.
Redirect urls will not help you because they are not used int eh client credential flow.
In general application only auth (client credential flow) + a broad authorization scope is very powerful, but must be managed correctly. You don't inadvertently want to build a totally new users/permissions model over the top of the graph :)
There are very few options available currently available to offer these controls at token issuance (in Azure AD) or at API access (in Microsoft Graph). However, you can achieve similar results by carefully managing access to the app's credentials. Here are a couple steps you can take (not exhaustive):
App credentials: keep them secret, keep them safe
Use Key Vault. You can configure many of the restrictions you mention for access to data in Key Vault, including IP ranges and which users access. Key Vault also offers auditing of access to secrets. Don't forget to also be careful about which users have management access to the Key Vault (e.g. other users with access to the same Azure subscription).
Use certificates (public/private key pair), rather than client secrets (passwords), to authenticate the app. People tend to manage certificates much more carefully than they manage shared passwords, and developers are much less likely to hard-code the secret into scripts/code.
Be careful and deliberate about which users can manage the app's credentials
This is often overlooked. A user (or another app) who can access existing credentials, or add a new authorized credential to an app can act as the app and (mis)use all the permissions the app has been granted. This includes:
Users (and apps) in the "Company Administrator", "Application Administrator" and "Cloud Application Administrator" directory roles.
Users who are set as owners of the app registration (Application object) and enterprise app (ServicePrincipal object) for the app.
Users (or systems) who have access to the server or service the application resides on (which will have, or have access to, the credentials).
For all of these cases, ensure this is the smallest possible number of users, and they actually have a legitimate need. For users who do need access, wherever possible enforce just-in-time, time-limited access (not persistent access), such as with Azure AD Privileged Identity Management, for time-bound, just-in-time access for Azure AD directory roles and Azure resources.
I have enabled the modules Two Factor Authentication and TFA Basic Plugins. I am using TOTP as my validation plugin. I had downloaded the Google Authentication app on my mobile device.
I have successfully done TOTP Authentication on my admin account. However, I have several authenticate user accounts I need to make. How can I set there accounts so that they can do TOTP Authentication?
Currently if I create a user/password for them then go to security, I see the TOTP Authentication screen where I can scan. However, how do I give the user the ability ?
If I provide them user/password but want them to have TOTP setup to there mobile device how do I do that?
Thanks in advance,
Mike
You may have come across this by now, but there is a permission "Set up TFA for account" provided by TFA Basic, which you'll want to ensure you set for relevant roles (which may well be simply "authenticated user").
In case you were looking to use the "require TFA" for a role, then any user with that role will be unable to log in all by themselves, and will get an error "Login disallowed. You are required to set up two-factor authentication. Please contact a site administrator".
Therefore, if you wish to enforce TFA, you'll need to do some custom implementation unless you're in a position to walk each user through initial setup (I suspect not). https://www.drupal.org/node/2622030 should provide some pointers for this.
You could consider https://www.drupal.org/project/tfa_rules instead of enforcing TFA: at the least it offers a default rule which encourages those who have not enabled TFA to do so.