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.
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
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 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.
Am developing a Windows Store 8.1 app using C# and xaml.
I am doing Single sign on using Azure Active Directory Account login.
I do not want users to be redirected to the Microsoft Account login screen, and then come back. I want to supply them with the login credential screen where we capture their username and password, and then we want to programatically do the authentication against Azure AD, and get back the claims identity.
How can i achieve this?
This is not a supported scenario for security concerns. One of the value propositions for AAD is that the password management, across the whole login lifecycle, is managed and secure. This is particularly important for scenarios in which AAD is securing a 3rd-party SaaS solution. A developer should not be able to have access to a user's credentials at any point.
All that said, it sounds like there is another question here which is answerable: How can I customize the login screen that AAD gives me?
AAD Premium does offer features for adding custom branding to your tenant. However, you still will be working with a screen that is provided for you.
I have a web application that we are building. We need a text editor to allow for our registered users to create and or edit documents. We want the documents to be used within our app, but would like to use the Google drive interface to create/edit/upload docs. What I am concerned about is the OAuth2 process. I would like for our web app to be the authenticator, and allow our users access to our files/folders that are under our account rather than theirs. Can we do this? All of our users are authenticated by our application already, and we do not want them to have to use their personal credentials to access files used by our application.
According to Google's documentation:
Each Gmail account intended and designed for use by an individual
user. If you have multiple users frequently accessing the same account
from various locations, you may reach a Gmail threshold and your
account will be temporarily locked down.
Anecdotal evidence confirms this: a worker at a school reported a 403 error possibly caused by too many people logging into the same account at the same time.