How can we mask/hide password claim so the developers who are troubleshooting the journeys do not see users passwords?
You can only hide PII when App Insights is in Production mode.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/troubleshoot-with-application-insights?pivots=b2c-custom-policy#configure-application-insights-in-production
There is no direct way to mask/hide/encrypt from Application Insight for Azure B2C. However here are the following workarounds you could test with:
Don't include claims with personal data.
Within Application insights technical profile AppInsights-Common, AppInsights-SignInRequest, AppInsights-UserSignUp and AppInsights-SignInComplete there should not be any claims transformation Input similar to InputClaim ClaimTypeReferenceId="passwordTransformation" or Output claims OutputClaim ClaimTypeReferenceId="plaintextPassword" TransformationClaimType="outputClaim" or InputClaim ClaimTypeReferenceId="password" TransformationClaimType="inputClaim
Do not set the DeploymentMode to Development in production environments
Logs collect all claims sent to and from identity providers. You as
the developer assume responsibility for any personal data collected
in your Application Insights logs. These detailed logs are collected
only when the policy is placed in DEVELOPER MODE. Refer to https://learn.microsoft.com/en-us/azure/active-directory-b2c/troubleshoot-with-application-insights?pivots=b2c-custom-policy#configure-application-insights-in-production
Thanks
Related
When working with Custom Policies in Azure AD B2C, you will typically see two kinds of applications being registered:
a web API, often called IdentityExperienceFramework
a native app, often called ProxyIdentityExperienceFramework
To quote from the tutorial on Custom Policies:
Azure AD B2C requires you to register two applications that it uses to sign up and sign in users with local accounts: IdentityExperienceFramework, a web API, and ProxyIdentityExperienceFramework, a native app with delegated permission to the IdentityExperienceFramework app. Your users can sign up with an email address or username and a password to access your tenant-registered applications, which creates a "local account." Local accounts exist only in your Azure AD B2C tenant.
What I have not found yet is a motivation why both applications are needed. All tutorials but also the official documentation skip over it. They only explain the steps for creating and registering the apps, but not their exact purpose.
Questions:
What is the difference between the IdentityExperienceFramework and the ProxyIdentityExperienceFramework?
Why are both applications needed in typical flows (e.g., sign-up/sign-in)?
Are there use cases where Custom Policies require only one of these applications? Or more then these two?
You need both and this is the only option. Services on our side are designed to work using this Native App+Resource app on our end. Also means you don’t need a client secret to be sent as part of the ROPC call that login-noninteractive makes. No, there is no other combination ever used or required.
About the sample "https://github.com/azure-ad-b2c/samples/tree/master/policies/impersonation".
Someone who has already used it, can you comment on how you handled the authentication logs? I noticed in the B2C Logs both the user who is "Impersonated" and the user who is "Impersonator", I did not find any records that indicate that there was an "impersonation" process.
The Token generated in this process is for the "Impersonator" user, and has information about him, is it possible to bring information about the "Impersonated" user?
There will be nothing official in the logs generated by AAD B2C for this impersonation, and AAD B2C does not know the context of your AAD B2C policy. It can only understand that a token is issued for a particular user, not a custom process that allowed it.
What you can do is use App Insights to inject your own custom events to create logs.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/analytics-with-application-insights?pivots=b2c-custom-policy
We have a simple scenario but technologies(or implementation) have made things bit complex -
We have Sitecore as CMS for client's main web site and for business functionality we have Dynamics 365 Portal and we are using Azure AD B2C as identity provider for both.
We have heavily customised B2C custom policy to cater specific requirements.
We are using same custom policy in Sitecore and in Dynamics 365 Portals so sign in individually and works perfect without any issues.
With regards to SSO, we have kept the configuration as OOTB as you can find it here.
Only 1 or 2 user journeys are absolutely perfect as good as seamless journeys. In specific journeys we need user to be logged in both ends to make it work (we can force user to go to sign in page, but it is not required on all the pages).
In order to understand how real and proper SSO should work in Azure AD B2C, I have no idea or experience to relate this process to. so I am looking for guidance and help here.
I found very good information in this about how B2C works in terms of signin and providing tokens process but it bit old question and things have changed a lot since then specifically UI and some of the operations.
Use the following docs when configuring sessions management for a custom policy. Session Behavior section is where you define which SSO behavior. Specifically:
<SingleSignOn Scope="Application" />
If you want your users to get SSO between all applications, then define this value as "Tenant". There are several useful scenarios in creating separation between sessions - such as a company that has multiple brands that do not want to conflict each other. Or a separation of experiences.
Follow the exact format and location to be placed in your policy or you will not get the desired result.
Another concept that is important is the understanding the session provider:
SSO session management has two parts. The first deals with the user's interactions directly with Azure AD B2C and the other deals with the user's interactions with external parties such as Facebook. Azure AD B2C does not override or bypass SSO sessions that might be held by external parties. Rather the route through Azure AD B2C to get to the external party is “remembered”, avoiding the need to reprompt the user to select their social or enterprise identity provider. The ultimate SSO decision remains with the external party.
Session providers are used to define maintain what goes into generating the session when your policy is being executed (inside the Identity Experience Framework). If marked incorrectly, this could lead to undesirable results such as wrong claims being sent, additional MFA prompts, parts of your policy not being maintained when ran or just general errors.
This is for those who are interested in how we achieved this -
Sitecore also does offer OOTB Azure AD B2C configuration however the supplier of Sitecore delivery side decided not to use OOTB configuration approach and hence it caused lot of issues. From what I have read about Sitecore configuration for Azure AD B2C it does work smoothly with B2C with careful configuration.
Work Around: We had to rely on external triggers(e.g. cookie) which will indicate and trigger that a user has signed on either sides and accordingly the sign in process on both side kicks off.
We are leveraging Azure AD B2C Custom policies with our web application. When we do an important transaction on the app, even if the user is logged in, we would like to be able to verify that this is the correct user before committing the transaction. For instance, we could send a code to the user's phone and ask him to enter the code in the app (on the form he is executing the transaction).
Is this something achievable thru Azure AD B2C Custom policies ? MFA phone factor extension?
Yes, the Azure Multi-Factor Authentication Software Development Kit (SDK) can let you build two-step verification directly into transaction processes of applications in your Azure AD tenant.
For the details about the code sample, you could refer to here.
Note: This feature will no longer be supported until November 14, 2018.
We would like to use Azure AD B2C for our web applications to allow users to sign in either with a 'local' account/password or use their social accounts (Facebook, etc).
https://learn.microsoft.com/azure/active-directory-b2c/active-directory-b2c-overview
However, in this application, we are likely to be targeting organisations, so we would also like to integrate with a company's existing Azure AD corporate accounts. That way the user doesn't have to create a new account and can use their existing corporate account.
It turns out that there is a (new) feature within Azure AD B2C which allows you to explicitly link to an external Azure AD account by using a custom policy as described here: https://learn.microsoft.com/azure/active-directory-b2c/active-directory-b2c-setup-aad-custom
Unfortunately, this only works if we know in advance which external companies we need to link with and add in specific configuration. It also leaks information about who is using the app, because the company names become listed as options on the sign-in page.
I've also looked at the Azure AD B2B features, but I don't think that this fits properly either.
What we'd really like is for Azure AD B2C to offer a generic sign in to a (corporate) Microsoft account', which detects whether that email address is already handled within any Azure AD systems; if it is, it then delegates authentication to that system, but if not, it will fall back to an Azure AD B2C local account.
This generic login already works for access to standard Microsoft apps, such as their portals. Does anyone know if this is possible within Azure AD B2C, or have any potential timescale for when it may become possible?
Are there any alternate systems which may be able to offer similar functionality?
What you are referring to is having Azure AD in multi-tenant mode, added as an identity provider to Azure AD B2C.
From: Multi-Tenant Azure AD Auth in Azure AD B2C with Custom Policies
In order to support multi-tenant Azure AD, you'll need to configure your ClaimsProvider in the custom policy with different values.
Use the values below, making sure you replace with client_id and IdTokenAudience.
<Item Key="DiscoverMetadataByTokenIssuer">true</Item>
<Item Key="ValidTokenIssuerPrefixes">https://sts.windows.net/</Item>
<Item Key="authorization_endpoint">https://login.microsoftonline.com/common/oauth2/authorize</Item>
<Item Key="client_id">df5b2515-a8d2-4d91-ab4f-eac6e1e416c2</Item>
<Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
<Item Key="scope">openid</Item>
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="response_types">id_token</Item>
<Item Key="IdTokenAudience">df5b2515-a8d2-4d91-ab4f-eac6e1e416c2</Item>
CAUTION: This functionality isn't officially even in preview yet, so use with caution. Keep monitoring the official "Sign in by using Azure AD accounts" documentation to see when this is fully documented and supported.
EDIT: Make sure you flip the Multi-tenanted switch in the App's settings, otherwise you'll get the following error:
AADSTS70001: Application with identifier '(guid)' was not found in the directory (our company's primary domain)
Azure AD B2C does not officially support a multi-tenant Azure AD identity provider. You should vote for the feature here so it can help prioritize it and so that you can be contacted when the feature is in preview.
There is a potential workaround if you have a limited set of Azure AD tenants that you work with. You could build a page in your app where the user types in the email address. Based on the email address, you can use the domain_hint parameter when calling Azure AD B2C to redirect them directly to the right sign-in page.