When I want to publish my XF.UWP app to the Microsoft store on a new pc I am presented with the following fields to fill:
Tenant ID
Client ID
Client Key
The Microsoft documentation page that guides you through the process seems to be outdated (I already reported this), and I can't find the data that I need to fill from the new Microsoft Partner Center.
The only field I am able to find is 'Tenant Id'. I Found it under gear icon - account settings - organisation profile - tennants.
Who can help me out
Like with many of Microsoft's services, the Client ID/ Client Key location is a bit vague and easier to explain with screenshots than words. But for anyone who may not understand the purpose, I'll leave a brief synopsis to explain the caveman drawings below.
The tenant ID in this scenario is the ID of your Azure AD tenant. No big surprises here. You can grab this (assuming an Azure AD organization is already linked to your Microsoft Partner Center account) from the MPC dashboard under Home > Account Settings > Organization profile > Tenants.
The client ID & client key are slightly harder to locate. This is because MPC recognizes three types of entities within the user hierarchy.
Users
Groups
Azure AD applications
To take advantage of the current automated publishing pipeline for the Microsoft Store, you must create or manage the Azure AD application associated with your project, which can be done under Home > Account settings > User management > Azure AD applications.
If you are familiar with GCP or Google API integration, the Azure AD app is the equivalent of a service account. A given Azure AD application can be assigned any permission within the scope of your project or even your organization based on the scenario. In my experience, the Manager role has always been sufficient.
Click an existing app to manage or create a new one from scratch; either way, you will soon reach the Client ID / Client Key panel, where you can add, view (one time only), and delete keys for your application. The values generated here can be utilized in the Microsoft Store submission workflow seen in the OP's screenshot above. Happy publishing!
References: Add users, groups, and Azure AD applications to your Partner Center account
Do you have Azure AD linked to your account?
If so, those keys should be available here:
https://partner.microsoft.com/en-us/dashboard/account/v3/usermanagement#users
If not, it can be configured here:
https://partner.microsoft.com/en-us/dashboard/account/TenantSetup
leading to:
https://partner.microsoft.com/en-us/dashboard/Account/CreateTenant
Related
I've been setting up custom policies in Azure AD B2C that take elements from a number of different examples including email invite signup, social and local accounts, and api connectors.
Because of that, I've pulled together code from approximately 10 different example repos and 30 pages of Microsoft documentation.
Now I'm going back through everything I've built and trying to note, more completely, what pieces of the infrastructure are responsible for what functionality.
In the B2C Tenant, in the Identity Experience Framework page, under the Policy Keys page, I have an entry for AdminClientEncryptionKeyContainer (auto-prefixed as B2C_1A_AdminClientEncryptionKeyContainer) which I have no recollection of creating, and can find very little reference to on Google.
Where did B2C_1A_AdminClientEncryptionKeyContainer come from and what does it do?
In an Azure AD B2C tenant the B2C_1A_AdminClientEncryptionKeyContainer Policy Key is created automatically when you create a new Policy Key with the "Options" of "Manual".
If you're following the Microsoft Docs tutorial for user flows and custom policies, this will be the step when you Create the Facebook key.
My assumption, though I don't know for certain, is that it's required for encrypting the Secret of a manually created policy key.
I have followed the instructions on this page to add the ability to sign up / log in to my application using a Microsoft Account. Personal accounts seem to work fine, but organizational IDs do not. And if I type in an email address that is both an organizational ID as well as a personal account, at no point am I prompted to choose "Work or school account" vs. "Personal account". When I use the same email to log into Azure, I am prompted to pick one.
The configuration instructions talk specifically about enabling "Accounts in any organizational directory and personal Microsoft accounts (e.g. Skype, Xbox, Outlook.com)." and I have confirmed that this option is set properly in my registered application.
Is there something else I need to do to enable sign up and log in with organizational IDs in my AADB2C application?
Although you registered an app with the type is Accounts in any organizational directory and personal Microsoft accounts (e.g. Skype, Xbox, Outlook.com), it doesn't mean you have enabled sign-in for users from an Azure Active Directory (Azure AD) organization.
The configuration in this article is only for MSA. You define the account as a claims provider that Azure AD B2C can communicate with through an endpoint by adding a claims provider.
If you want to enable sign-in for Azure AD users, you should define Azure AD as a claims provider.
You should finish the configuration on this page.
This is driving me nuts. I've successfully followed the Android Management API Quickstart to create a project/enterprise/policy and install it on a device.
I stupidly didn't write down the enterprise or policy IDs. I tried to create a new set, but the non-enterprise email now gives an error that it's already part of another EMM.
Is there a place in the console where I can see a list of the enterprises and/or policies that I've created? Where are these stored?
Edit: I found the enterprises.get method in the API but if I put enterprises/* in the name field (per the validation) I get a 400 error indicating Invalid enterprise id. Provide a valid id. so I'm unsure how to move forward.
You can find the enterprise you created by logging into play.google.com/work with the account that was used to create it.
Click on Admin Settings to see the Organization name and Organization ID
And to find the policies of all the devices you have enrolled to this enterprise, you can simply call the API - enterprises.devices.list entering the parent in the form enterprises/{enterpriseId} [ enterpriseId here is the OrganizationID that you get from the above steps ]
This would list all the devices attached to the enterprise and in the response you can find policyName of each device.
I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.
Trying to figure out if I can do the following via the box-api.
authenticate as an enterprise admin
lookup a user (in our case a special box user named "group_xxx" where this account will serve as a non-person shared group like "group_math_dept", "group_engineering_dept", etc...).
query for the root folder info for a given user-id (perhaps "GET /users//folders/0"
(tried that it doesn't work).
View the list of enterprise users with whom the given folder has been shared.
Modify the list of enterprise users with whom the given folder has been shared.
What I'd like to do is develop an app to delegate admin of these special group accounts to an appropriate individual in the given group. We can maintain who admins what locally. I can authenticate as one of our Box Admins (i.e. I have working code for steps 1 and 2). However, I don't see support in the API v2.0 doc for steps 3, 4, and 5.
Am I missing anything?
Unfortunately my understanding is the same as what you've found; that account and meta operations like steps 3 through 5 are not currently supported through the API.
UPDATE:
Looking at Box's developers blog it looks like functionality for steps 4 and 5 were actually just added, but are not yet in the documentation.
http://developers.blog.box.com/2012/09/10/v2-api-updates-keep-rolling/
Box actually has some more enterprise/admin API methods in private beta. Those are made accessible to early testers for a controlled environment, and include methods to perform operations on behalf of other users with administrative privileges.
If you're interested, feel free to email api [at] box [dot] com to discuss the testing of beta methods.