Does Azure B2C have an end user portal "app endpoint" dashboard? - azure-active-directory

Is there any Azure B2C end-user queryable endpoint that will allow that owner to identify which tenants they have authenticated to?
A dashboard for B2C users that is an aggregate of all tenants they have federated with? Is there some extension of the /common endpoint I could make an OAuth query to? (ideally including AAD B2B guest accounts)
https://account.live.com/Activity
https://account.activedirectory.windowsazure.com/r#/applications
myapps.microsoft.com
4/24/20 Edit:
I found this in the portal that implies a portal is available.
I'm looking for the API in which to programmatically add applications to it before a migration.
I need to have the applications already 'signed in' or linked to applications I own in the B2C directory (OIDC/SAML2 apps)

Your question is the equivalent of asking, "Can i find out if i registered at StackOverflow and Facebook with this/my email?". You cannot do this, AAD B2C is isolated tenancies representing a single organisations' identities. There is no equivalent of /common endpoint for AAD B2C. In AAD and AAD B2B accounts, there is a mapping created from the original account to identify which tenants they are in. This is to maintain a single identity across the Microsoft ecosystem.
In AAD B2C, this doesn't exist, goes back to my first sentence for 'why', they are separate applications, and inherently have no relationship, nor do the identities.

Related

Is it possible to allow all users in a specific AAD tenant to access an app?

Is it possible to allow all users in a specific AAD tenant to access an app?
Something like a tenant trust. Tenant 1 trusts Tenant 2 and I can add 'tenant2\AllUsers' to a permission.
I want to allow all users of a partner tenant (current and future) to be able to access a SharePoint site and a few other apps.
I've looked at B2B but it requires invitations which is hard to manage at scale.
Entitlement management looks nice but requires P2 licenses and has lots of capabilities we just don't need.
Does anyone have a simple way to do a 'tenant trust'? Am I missing something?
Firstly, you have a misunderstanding of "tenant trust".
When we say tenant trust, it means the tenant trusts an app and then the app can access the data of that tenant. There is not a way to make a tenant trust another tenant.
Anyway, using the official admin consent URL you can grant admin consent for a whole tenant to an app.
See Construct the URL for granting tenant-wide admin consent.
https://login.microsoftonline.com/{tenant-id of partner tenant}/adminconsent?client_id={client-id}
Sign in with an admin account from partner tenant and do the admin consent. Then all users from partner tenant can sign in to this app.
For SharePoint user case, you can take advantage of self-enroll service. Please refer to Use SharePoint as a business-to-business (B2B) extranet solution and Create a B2B extranet with managed guests.

Login via SSO (SAML) for ANY user from the Internet (not just a corporate one)

I have included SSO (SAML) authorization in my existing application. But for me it was an unpleasant surprise to find that only 2 types of users can use the login through the providers I added (Okta, Azure AD):
Users who are located in the corporate directory of the provider (for example, I made an application on my account, there are no more
users. This means that any other user will not be able to use the
login form, because he is not a member of my tenant)
Third-party users of companies, whose administrators have added a
template of my application from the general list and connected their
users to it.
I expected other results, I need ANY user to be able to log in through these providers (regardless of whether he is in the corporate directory or has his own separate account that is not integrated into my application)
I thought about changing the SAML protocol to OIDC (OpenID Connect), but it seems to me that everything will work in the same way (at least Azure AD, because it seems there are no other options for working with it, except for corporate distribution)
Who had a similar experience, could you tell me what I should use among technologies and protocols so that ABSOLUTELY ANY user can log into my application through Okta / Azure AD / Google? Thanks!
Azure AD login fail screen
Okta login fail screen
You can use Azure AD OAuth2 flows and multitenant apps with MSA (personal account) support to allow any user from any domains and personal accounts to login into your application. Or you can switch to Azure AD B2C (which also relies on OAuth2) to connect different identity providers (Local Azure B2C, Azure AD, Facebook, Google, Amazon, Github, Linked in, Twitter, generics, etc) and allow all their users to login into your application.

Combining custom registration and Azure AD?

I'm in a pickle, lacking the experiences that would provide me with guidance in my project and am seeking pointers from those for whom have Azure AD, SSO and Federation experience.
I am building an employee self service system and using Azure AD for identity management. I would like the user to be able to sign in using their employee ID # and password, not their email address; there should also be an option for the user to register for online access using their employee ID # and other personal information - their Azure Identity already having been established by humane resources.
The sign in flow would take the user to the Microsoft login page which would in turn detect that the user needs to sign in via a custom login page and redirect them there. Once they are signed in, my server would transmit their identity to Azure AD and grant them access based on the Azure Application permissions.
I'm simply really confused about how to start setting this up, if it's even possible. I'm aware of XSS but isn't Federation and SSO with SAML2 secure?
Do I need to use a federation application as a middle-man such as Ping Identity?
Thanks for any help!
Using e.g. Ping as an IDP generally won't help because Azure AD is already an IDP.
Microsoft Azure AD login pages can't be accessed by API and can't be customised to the extent you want.
And you can only sign-in with an email address because it's designed for domain-joined corporate customers.
You can do a lot of what you require with Azure AD B2C and custom policies. That will allow you to sign-in with a user name (= employee id) and you can create workflows.
You could then federate Azure AD and Azure AD B2C.
Your other option is to use an IDP that does allow authentication via an API e.g. Auth0.
Then you could have a custom login page that authenticates as appropriate.
Using Ping ID and other similar products is the fastest way to utilize SSO.

What is the relationship between AAD B2C and AAD? [duplicate]

This question already has an answer here:
What's the difference between Azure AD B2C tenant and normal Azure AD tenant?
(1 answer)
Closed 3 years ago.
I am currently the admin for an AAD B2C tenant (I can add B2C applications, flows/policies, etc.) but I can view only some AAD stuff. I understand that AAD B2C is a different service that is somewhat under our organization's AAD umbrella, but I don't have access to the AAD configuration.
I noticed that all the AAD B2C users are also shown as AAD users, and any new B2C app automatically appears in the App Registrations on the leftmost blade in the Azure portal.
All these make me think that AAD B2C uses AAD underneath. This is indirectly confirmed by the existence of a special application registered with the AAD (named "b2c-extensions-app. Do not modify. Used by AADB2C for storing user data."), which serves as a bridge between the two.
Does anybody know any more details about this relationship? I searched a lot but couldn't find much about it.
Azure AD B2C tenants (i.e. directories) are special-purpose Azure AD tenants with some features (and some limitations) specifically designed for B2C scenarios.
So yes, Azure AD B2C uses "regular" Azure AD for the core directory infrastructure, and adds all of the consumer-centric capabilities (sign-in/sign-up flows, Identity Experience Framework policies, full branding customization, etc.).

Lock Microsoft Graph access to only one domain

I have searched far and wide to find out how I can change the settings of my Microsoft Graph app so I only allow login from my own domain.
Since the login from Graph takes all Microsoft accounts i've been looking into different solutions, all from finding custom token endpoints to changing the application manifest.
In my manifest I can find this "signInAudience": "AzureADandPersonalMicrosoftAccount" - but I can't find in the documentation what other options there are.
also on this Microsoft page I can find this information
The overall solution comprises the following components:
Azure AD – If the Restrict-Access-To-Tenants: <permitted tenant list> is present, Azure AD only issues security tokens for the permitted tenants.
Is there any good guides online or anyone who knows how i can restrict access to people signing in either with #xxxxx.comonly or xxxxx.onmicrosoft.com accounts?
I think you're misunderstanding how Microsoft Graph works. It connects to the tenant/domain of the user authenticating. So if I authenticate with user#contoso.com, the application will only have access to the contoso.com tenant.
In terms of the authentication process itself, this is handled by Azure AD. Microsoft Graph simply accepts the token AAD returns. You can limit this process to users from a given tenant by changing the /Authorization and /Token URLs your app is using.
In most cases, apps use the /common tenant. When a user authenticates against /common, AAD handles discovering the user's actual tenant/domain and routes the request to that AAD instance for processing. These URLs look like this:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
If you want to limit authentication to a single tenant, you can skip the discovery process and force AAD/OAuth to authenticate against a single AAD tenant. Only users that exist in that tenant will be able to authenticate. This is done by swapping /common with tenant's id:
https://login.microsoftonline.com/xxxxx.onmicrosoft.com/oauth2/v2.0/authorize
https://login.microsoftonline.com/xxxxx.onmicrosoft.com/oauth2/v2.0/token

Resources