I am having difficulty logging claim exchanges between technical profiles. I have set up Application Insights as described here (https://learn.microsoft.com/en-us/azure/active-directory-b2c/troubleshoot-with-application-insights) and this seems to work just fine - except that the traces provide me with no information about input and output claim values at various stages of a user journey. This is especially problematic when an error in the journey is caused by a missing claim.
Is there a way to record this information as part of the trace?
Related
I got reported an error including a correlation ID that I can't find in Sign In or Audit Logs in B2C.
I'm using B2C Custom Policies.
How can I make sure that I get at least some kind of brief information (in production) for every error that occurs when a custom policy is being called?
I already had a look into Application Insights technical profiles, but don't really think that it's something that could be used to accomplish what I'm looking for.
Any ideas?
I have several days trying to customize the email verification of my project but it's been impossible to change anything.
I followed many times:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-get-started
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-email-sendgrid
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-email-mailjet
I uploaded the new custom policies B2C_1A_TrustFrameworkBase and B2C_1A_TrustFrameworkExtensions with all the changes described in the manual, but I still don't know why I can't even generate an application error and the default Microsoft email verification keeps working normally, is there any way to track what I might be missing?
You can refer to the troubleshoot documentation about turning the B2C engine into developer mode and tracking the B2C engine itself.
There is a separate documentation and technical profiles explaining how to use application insights to track user behavior during user journeys. You can discover more about this here: https://learn.microsoft.com/en-us/azure/active-directory-b2c/analytics-with-application-insights
I am trying to retreive/change the MFA number on a B2C account programatically. I don't really mind how its done, and I am aware of this SO question - https://stackoverflow.com/a/40858874/243905 but that was asked a long time ago and I had hoped it was different now.
I find the B2C docs are a bit lacking in clarity on this information, and although I am able to query the users using the method detailed here: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet
the object that is returned does not return the MFA details.
Is this possible through any means?
strongAuthenticationPhoneNumber can be issued in the resulting token, however it can't be edited using graph, for the moment. It's expected this capability will be available during the 2nd half of 2018.
As of today this appears to be working for Azure B2C. Microsoft Docs
There is an extra permission that the token will need. UserAuthenticationMethod.ReadWrite.All
I am developing a Azure AD B2C Identity Experience Framework application (our AAD B2C IEF POC as we like to call it - sadly we lost the Private Premium Preview (PPP) part).
In the custom log in policies you can add an Application Insights key for logging. We have done that, and used the tracing successfully when we have had issues. I have on those occasions used analytics.applicationinsights.io/.../ to view traces.
However, at times I have noticed that the message is truncated. I checked the character count of one such message and it was 32768 characters long. This logging often contains complete SAML assertions sent as XML and can be quite long so this does not seem to be something out of the ordinary.
So, my questions:
Is 32768 the max length of the Message column in Application Insights and is that why my tracing is truncated? This answer suggests that the max length part is correct, at least.
Is there a way to recover data rows that have been truncated? That is - can I access the raw data from some table storage or something similar?
This is most important when there are errors so any way to see B2C errors that is not reliant on the tracing can help. But it is also relevant when the policy is executed successfully and we wish to see the assertions "pre transformations". So:
Are there any other way of logging the complete Azure AD B2C flow?
Or can B2C error be logged separately?
I have very little experience in both AI and B2C so I may be misusing terminology here. Feel free to correct me or ask if anything is incorrect or unclear.
Yes, the maximum length of the Message column in Trace is indeed 32768 characters
Message Trace message.
Max length: 32768 characters
Reference: Trace telemetry: Application Insights data model
No, the Message column is bound by the Trace telemetry: Application Insights data model, hence the raw data point for Message column which you export out to some storage account will also have the maximum length
Yes, the user journey recorder/player
This question is a continuation from How to pass required claims to OpenID identity provider with Azure ACS?
Its a slightly different take on the problem though, thus I'm posting this as a new question. Note: I'm also cross-posting this to the Azure Security forum but so far haven't gotten any useful input.
The Azure ACS samples shows that it is possible to add arbitrary OpenID identity providers to ACS. But for ACS to actually be helpful in our project as an STS for various popular providers we set out to get ACS working with MyOpenID.com (again, also used in the samples). The problem, as also the good Vittorio shows, is that MyOpenID will not give us claims like name and email address unless asked for. Vittorio and others states that this is because MyOpenID doesn't support Attribute Exchange.
I'm not so sure about that, though. Digging a bit deeper into the request url that ACS generates I can see that parameters like openid.ns.ax=http://openid.net/srv/ax/1.0 and openid.ax.required=email,fullname,firstname,lastname. Also, openid.ax.type.email is typed to the axschema.org/contact/email type. This is where things go wrong with MyOpenID. MyOpenID does not understand the axschema.org types and will thus not return an email value.
What I do know is that MyOpenID understands the schema.openid.net/contact/email type. So building on this I manually changed the ACS request url to use the openid.net schema instead of axschema. Lo and behold, MyOpenID reacts and shows that my email address in fact will be returned.
Here is a list of the parameters I'm trying to pass in to myopenid.com/server endpoint:
openid.ns=http://specs.openid.net/auth/2.0
openid.mode=checkid_setup
openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select
openid.identity=http://specs.openid.net/auth/2.0/identifier_select
openid.realm=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid
openid.return_to=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid...
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.required=email,fullname
openid.ax.type.email=http://schema.openid.net/contact/email
openid.ax.type.fullname=http://schema.openid.net/namePerson
Unfortunately, when the response is returned back to ACS it isn't good enough, and ACS fails with the following error codes:
HTTP Error Code: 400 Message: ACS30000: There was an error processing an OpenID sign-in response.
Inner Message: ACS90014: Missing required field 'openid.ax.value.email'.
Trace ID: f8e09e6f-0765-4370-9f03-f744cce6fa2a
Timestamp: 2011-08-02 17:12:57Z
I've tried adding additional fields without changing the original email type, but only get the same errors. I'm starting to suspect that it is in fact ACS that is not supporting AX to its full extent and that it is somewhat hardcoded to only accept claims of certain types.
The question is: does my request parameters look right to you or am I missing something obvious here?
NOTE: my initial setup is working, if I leave the ACS request unchanged and in ACS only configures a single Passthrough rule for the identity provider, I can successfully authenticate my website through ACS using the MyOpenID identity provider. The problem remains though that MyOpenID will not hand over e.g. FullName or Email to ACS if the request from ACS does not explicitly ask for the claim types http://schema.openid.net/namePerson or http://schema.openid.net/contact/email
For security reasons, ACS can't allow callers to retype the email address claim. Effectively, what you're unknowingly doing is attempting is a variant of attack 4.5 (OpenID Data Type Confusion) from this paper. For security reasons, ACS has to ensure that email address and the other AX claims it supports exactly match the types it is aware of, otherwise malicious callers could trick ACS and substitute one claim for another. It's not that ACS doesn't support AX, it's that ACS only supports a single claim type as the email claim, and it's not the same one MyOpenID uses. In short, this isn't going to work.