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.
Related
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
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.
We're trying to implement a Docusign integration for a multi-tenant cloud application (i.e. https://company1.app.com, https://company2.app.com, etc...).
The goal is to allow the tenant admin (our customer) to upload envelopes containing document templates for users to sign when they first login. Each tenant admin will have their own Docusign account/envelopes.
We've implemented a solution for this; however, it requires each tenant admin to create a separate Integration key and go through the process of promoting it to a live account. This is not scalable for us and some of our tenant admins are not tech people, so they have trouble setting this up.
Is there a way to implement the Docusign integration using a single Integration key (our key), but still have tenant admins login with their own Docusign account and upload their own envelopes?
I think you are building a Docusign User Application. You should use the OAuth2 auth flows instead of creating separate Integrator key for each tentant.
A user application is a client that authenticates every end user with DocuSign. These applications are typically web services, mobile applications, or desktop programs that authenticate individual users on the DocuSign platform. Once authenticated, users give consent for the application to display, send, or sign envelopes from their account. For user applications the OAuth2 auth flows are recommended.
A key issue that you may be missing is that your Integration Key works with any account. It is associated with your account just to manage it.
So as CodingDawg says, each of your customers can use your app by logging in with their own user credentials for their own account.
I have multi-tenant application, which exposes some API for our customers to use. I would like to expose it using Azure API Management. Mostly to provide Development Portal to our customers, which I find very useful, and maybe use some other features.
If I understand correctly, our customers will set up their own subscription keys for authentication, which API Management proxy will validate.
Question: How can I link and identify user/subscription to the tenant of my application, to ensure that only data from this tenant are returned.
One direction I can see to explore is to use delegated sign up, which I guess will help me to link subscription to the tenant. But then still the question is how to get user id in my backend API?
Any direction to documentation or samples is very appreciated
You could create separate groups in APIM to represent your tenants and then put users into those groups using delegation hookups. Withing APIM policy in expressions you can reference context.User.Groups to list groups user making the call belongs to and forward that information to backend.
Alternatively you could use Note field to store tenant name and access it as context.User.Note. Or if you're willing to store mapping on your side the just take an id context.User.Id.
All of above could be passed as a header using set-header policy like:
<set-header name="userId">
<value>#(context.User.Id)</value>
</set-user>
All scenarios would require you to have delegation setup to fill this information automatically for every new user created.
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.