I have an AzureB2C tenant which is federated with an external provider google.
I have deleted the user in google and the user is no longer login able to the application.
Is there any standard clean up procedure in AzureB2C to cleanup the deleted users data ?
As I know, if you don't delete the related external provider in the Azure B2C, you can only delete the user from the source provider like google provider delete user from google.
Related
I have a B2C tenant which is used for social login to the web app, I wanted to check regarding delete my account flow.
How can I invoke it for each user who want to delete their account?
When they click delete, it should delete their entry from B2C tenant.
I tried with Graph API but that requires admin role to do that, I want social users to delete their account.
Can user delete its account from B2C tenant directory?
I found this link but not sure how to implement it or use it.
https://github.com/azure-ad-b2c/samples/tree/master/policies/delete-my-account
This sample uses a custom policy.
If you look in the policy, you'll see it inherits from "B2C_1A_TrustFrameworkExtensions". You can find this file in the starter pack.
If you haven't set up the custom policy framework, this utility will help.
I'm currently setting up Azure B2C tenancy. As part of the setup, I'm integrating with external identities for the User to login. However, the requirement I have is that once signed-in using their external identities I want a corresponding user record to be created in my tenancy which I want to use later for application-specific role management & fine-grain access.
Thanks in advance for your help.
The described behavior is default and only supported one, for Azure AD B2C.
Once a user signs-in with their social identity provider, a "local" profile will be created - indicating basic info, like which social IDP the user is using, any info provided by the provider, any additional info that you explicitly required from the user (via user attributes).
You can later use this "local profile" for manage user's info. Here is an example of such user profiles in a B2C tenant:
You see some users coming from Gmail, some from Facebook, some from "other" (which is actually Microsoft365 in my case).
I have implemented custom policies to link external accounts to B2C local users during signin, as described here. For context, I pre-create local users in the directory with their signInName equal to their issuer email address. When users from external AD tenants enter the sign flow, I can then look them up with the technical profile AAD-UserReadUsingEmailAddress.
This works great and allows us to pre-provision and authorize users in our apps before the users' first signin attempt. However it appears that no login events are being recorded in the SignIn logs accessible through the portal.
Am I missing something? If not, seems I'll need to capture my own logs. I could write out to an Az Function from the User Journey, but it would really be preferred to write to the directory so logins events are visible in the portal. Is there a way to do this? I can easily call AzureAD GraphAPI if it offers the capability.
Thanks
Mark
I believe a sign-in log is only created for a local account sign-in, not an external account sign-in, as per your sign-in flow.
The audit logs, however, should contain the following activities:
An Issue an id_token to the application or Issue an authorization code to the application activity containing the local account user identifier and, if an external identity provider was used, then the identity provider name, identity provider client identifier, and identity provider user identifier
For a local account sign-in, a Validate local account credentials activity containing the local account user identifier and sign-in name; or
For an external account sign-in, a Federate with an identity provider activity containing the identity provider name, identity provider client identifier, and identity provider user identifier
You can also create a custom event from the sign-in policy to Azure Application Insights.
I thougt this toggle in Azure would enable for external users to log in:
But when I log in from an external account, I get:
AADSTS50020: User account 'xx#xx.se' from identity provider 'https://sts.windows.net/123123/' does not exist in tenant 'YY' and cannot access the application 'sdfsdfs'(asdasd) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
Do I have to manually add single accounts to let them login with Azure? Can't I open up for specific domains or all?
If you want users from the other organizations to login your application. There are four simple steps.
1.Update your application registration to be multi-tenant
2.Update your code to send requests to the /common endpoint
3.Update your code to handle multiple issuer values
4.Understand user and admin consent and make appropriate code changes
For more details, you can refer to https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant#update-registration-to-be-multi-tenant
We have a Web App secured with Azure AD B2C using custom Identity Experience Framework policies to allow users to register and sign in with social identities (Microsoft, Google, Facebook), or with an identity from another federated Azure AD instance, or with 'local' Email / Password accounts.
All the social accounts and the Federated AD work correctly. Sign up and sign in with Email/Password was working correctly, but we are now experiencing an error. We haven't knowingly made any changes to our Email/Password configuration since this was last known to be working, so we're not sure how this has happened.
The issue is: Sign Up with a new Email Address works correctly, and after the process completes, the user is correctly logged-in, and their account appears in the directory. If the user signs out, however, then any attempt to sign back in again fails:
(Email address shown is not the actual one. Error has been repeated by multiple users with new and old email/password combinations.)
Digging into the portal, the underlying error is revealed as:
70001 The application named X was not found in the tenant named Y. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.
This error appears sometimes to be related to a failure to grant permissions to an application in the portal. We have tried removing and reinstating all permissions, and re-granting permissions. This has not solved the issue.
Does anyone know what could be causing this issue, and in particular why sign up / sign in works correctly, but returning sign in does not?
UPDATE:
Just to confirm that we have the IEF and Proxy IEF apps configured in the AD directory:
And we have the login-NonInteractive technical profile configured in TrustFrameworkExtensions.xml:
Having wired up Application Insights (following these instructions https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-troubleshoot-custom), we're able to get to this more detailed error:
AADSTS70001: Application with identifier
'ProxyIdentityExperienceFrameworkAppID' was not found in the directory
weapageengine.onmicrosoft.com
The only place 'ProxyIdentityExperienceFrameworkAppID' appears in any of our custom policies is shown in the XML snipped above, but this seems correct as per the documentation here: https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38 - unless we are meant to update those 'DefaultValue' attributes as well?
Resolution:
As per the answer below, it is necessary to update both the Metadata and the default values with the relevant app ids. Worth noting that in the GitHub sample https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/3b4898fec3bf0014b320beffa6eb52ad68eb6111/SocialAndLocalAccounts/TrustFrameworkExtensions.xml#L38 the boilerplate values are differently cased, leading to our missing one in a replace-all:
The local account sign-in authenticates the end user against the Azure AD B2C directory and then reads the user object from it.
The local account sign-up and the social account sign-in do not authenticate the end user against the Azure AD B2C directory. The local account sign-up writes the user object to it. The social account sign-in delegates authentication to the social identity provider and then either writes the user object to the Azure AD B2C directory if the user object does not exist or reads the user object from the Azure AD B2C directory if the user object does exist.
To enable authentication of the end user by the local account sign-in against the Azure AD B2C directory, you must add the Identity Experience Framework applications to the Azure AD B2C directory and then configure these IEF applications with the login-NonInteractive technical profile.
The local account sign-up and the social account sign-in do not require these applications.