I'm using "AppDomain.CurrentDomain.AssemblyResolve" in my multi tenant application and in the Assembly Resolve method, I'm planning to resolve the dll based on the current tenant.
The problem is that Assembly Resolve method always refer to the first request context. I understand that as Assembly Resolve is registered at the AppDomain, it will use the same context that it received during the first call.
My question is:
What are other options to resolve the assembly per tenant?
I need to know the tenant context in Assembly Resolve somehow.
I tried to un-register and re-register the AssemblyResolve event, but that isn't possible either.
Related
I am struggling to create and configure an Azure Enterprise Application.
I have been trying to accomplish this task via PowerShell. I attempted to create an enterprise application by making use of the tags an application registration can have by following this github post, which essentially boils down to adding this tag to the service principal:
$tags = #("WindowsAzureActiveDirectoryIntegratedApp")
From there, I seem to be having problems with adding an identifier uri to the application. Here is the error:
Values of identifierUris property must use a verified domain of the organization or its subdomain
This error does occur to me whether I try this using PowerShell or Terraform.
I think it might be possible to resolve this error by adding the url as a custom domain, but the weird thing is that this url is used by the enterprise application that is setup manually, so I'm a little confused by this error and think the problem might be more than just adding the url as a custom domain.
I would like to note that at this point if I remove the identifierUris the application registration and service principal are both created, but if I were to go to SAML section of the service principal, there does not seem to be a way to manually upload a SAML metadata file (via PowerShell only - it does work in Terraform, interestingly enough).
This brings me to the other issue that I face for configuration: SSO configuration, specifically via SAML. I would like to programmatically upload a SAML metadata file and then modify some of the fields in the SAML section of the service principal from the result of that upload. However, I have been unable to find a way to do this or find an equivalent workaround.
EDIT: Turns out you can upload a token certificate to the service principal via Terraform - for more info on the command see here. You will need to transform your data into an accepted value format (I would recommend .pem if you are coming from a .xml file). I am not 100% sure if this command works yet, as I am left with this message under the SAML Certificates section:
**Token signing certificate**
A certificate has been successfully created. Please reload the page to make it active.
And reload doesn't seem to be working yet...
Issues still left to address:
Identifier uri (previously mentioned)
How to edit the Attributes & Claims fields
EDIT 2:
So I was able to uncover this resource, which offers a step by step guide for automating away SAML-based single sign-on via MS Graph.
Still testing it - and there are some parts that can only be done on Windows (creating a custom certificate) - but this seems very helpful.
Based on my early testing, the only problem I have found with this method so far tis that might not edit the Attributes and Claims section of SAML SSO. However, I believe by creating your own application template this method solves the identifier issue I was running into.
So, the MsGraph tutorial largely covers most of what I needed for my usecase. A few things of difference that I would note:
I used a template application that suited my needs better*.
Attributes and claims are fixed by following the tutorials points on creating and assigning a claims mapping policy. You will not be able to see this through the GUI. Additionally, getting the updated service principal also does not display this configuration**.
If you have difficulty updating your logoutUrl I would see this github post - you can configure it via az rest, PATCH, and this endpoint: "https://graph.microsoft.com/v1.0/applications/$($app_id)".
Tying it all together is a little annoying via PowerShell as it seems that some of the commands take longer to process than others. As a result, I would recommend implementing some sort of retry into your script and even calling Start-Sleep so that future cmdlets recognize resources created by the ones that have already been called.
*Note the process of finding a template that works best for you can be a bit tricky if you do not already have one in mind. I ended up selecting the template that matched the enterprise application I was using when doing this process manually. I am unsure if every enterprise application available has a template that matches it.
**The only way to get a confirmation that a new claims mapping policy worked is to see this message (under the Edit section of Attributes & Claims, which is in the SSO section of the service principal): "This configuration was overwritten by a claims mapping policy created via Graph/PowerShell. Learn More.".
We followed the example for magic links from here
https://github.com/azure-ad-b2c/samples/tree/master/policies/sign-in-with-magic-link
We can generate the magic link, are redirected to our application with an "id_token" but we get error "message.state is null or empty".
We assume that we need to follow the instructions for production use in chapter "Using this in your Production Application" on the page above, but we don't understand how we can use the "authentication library" to generate the magic link for us as described. Maybe this library would append a "state" to our magic link which is then validated by B2C.
Is there any working sample code which works in production systems for magic links?
Update:
We use already a B2C policy "B2C_1A_signup_signin" (for local and social accounts) with callback path "/signin-oidc". Therefore we added with "services.AddMicrosoftIdentityWebAppAuthentication" another callback path for the magic link "/signin-oidc-magic" with a second policy "B2C_1A_signup_signin_magic".
We generate the magic link "manually" (like in the sample project) with "/signin-oidc-magic" as return url.
B2C redirects correctly to this callback path, and the OpenIdConnectEvents for the second callback path are raised, but in event OnRemoteFailure we get the error message "message.state" is null.
Should we merge both policies? Or is something wrong in our approach?
You need to pass the hint parameter to your app, and have your apps authentication library pass it in an authentication request to B2C.
JS: https://learn.microsoft.com/en-us/azure/active-directory-b2c/enable-authentication-spa-app-options#pass-an-id-token-hint
.Net: https://learn.microsoft.com/en-us/azure/active-directory-b2c/enable-authentication-web-application-options#pass-an-id-token-hint
I struggled with this myself for a while. The way I understand it now, is that in order for the magic link to redirect properly to your application after getting the token back from Ad B2C it should not be passed straight to the 'Run now' link for the custom policy but first to your application to extract the token and then passed to the OnRedirectToIdentityProviderFunc as in the documentation mentioned in the answer above. It think that does mean that you need to merge the claims extraction technical profile in to the same custom policy as the regular signin/signup flow and you can't have 2 separate custom policies but I would like to get more clarification on this myself as this use case is definitely not obvious from the samples. What good is it if they can only redirect to a jwt.ms but not an actual application.
I have several client apps registered in the Azure portal. Each app has different scopes that are enabled/disabled. I used to be able to modify the scopes and save the updates for each of the register apps. Now I get the following error from the Azure portal:
Failed to update {my app} application. Error detail: Property identifierUris is invalid. [mURNc]
I also get this same error even if all I try to do is rename the client app. If I create a brand new app there are no issues. This appears to be a bug in the azure portal, but I'm looking for a workaround as I don't want to redefine all the scopes again, there are quite a few!
I've tried to rename things, change the client app ID, etc, but nothing seems to fix the issue, I get the same error. Again, this all used to work fine and now suddenly with no changes I get this issue.
The error says the identifierUris is invalid, but it isn't descriptive at all on which URI it is referring to. Any suggestions on how to correct this?
As junnas said, click try out the new experience in the Authentication tab of App registration and try again.
Also, when you see the above error, we recommend the following:
1.Edit the attributes individually in the manifest editor instead of uploading a previously downloaded manifest. Use the manifest reference table to understand the syntax and semantics of old and new attributes so that you can successfully edit the attributes you're interested in.
2.If your workflow requires you to save the manifests in your source repository for use later, we suggest rebasing the saved manifests in your repository with the one you see in the App registrations experience.
Hope this helps.
I have created three B2C applications:
TestWebApp
TestApiOne
TestApiTwo
Both API applications were created the exact same way. Web API access is enabled, reply URLs have been specified, an App ID URL has been assigned, and keys have been generated. Both APIs have an additional read and write scope.
In TestWebApp API access, I am able to add TestApiOne with all three scopes without an issue.
When trying to add TestApiTwo to the TestWebApp API access list, the operation fails with the following error.
Failed to add the API access. Reason: The B2C service has an internal
error. If you created this B2C directory just now, please try again
after couple of minutes. If the problem persists, please contact
Support
(https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2c-support/).
If you do not have a B2C directory you can refer
https://azure.microsoft.com/en-us/documentation/articles/active-directory-b2c-get-started/
I thought maybe there is a limit of one API per application. To test, I created a temporary application "TempApp". I received the same error displayed above while trying to add API access for both TestApiOne and TestApiTwo.
Has anyone else experienced this issue?
There's not a limit of one API per application. I have done research and it works fine by my side.
Please have a look at the guide and check your steps.
I have tried to replicate the issues that you are facing by putting diff redirect reply url domains and also by making one application to be native and one normal web app but it doesn't help.
Could you try to delete all the webapps and try making 1 and then adding another to it.
Then create the 3rd one.
Please check this or if you can share some screen shots. That would be helpful.
You can definitely add multiple web apps to api access of one web app.
I am currently following this script to make the direct API calls to graph and to ARM to programatically create an Active Directory Application, a Service Principal referencing that created App, and a role assignment to that created service principal.
It works well since I must only use JavaScript: https://github.com/Azure/azure-sdk-for-node/blob/master/Documentation/ServicePrincipal/spCreate.js
The problem is that trying to assign the role in the success callback of the service principal creation, at line 134, results in a 400 Error, stating that the service principal was not found. This issue occurs when trying to make the request immediately on the success callback, if I wait for about 20 seconds after the success callback of the service principal creation then the role assignment works.
So my question is, what would be the best way to deal with the role assignment without the need of setting a sleep/setTimeOut to wait for the changes to propagate in Azure? Is there some other webhook/event or something that signals that the service principal is available?
There is no such webhook/event for this scenario. As a workaround, you may check the result of role assignment, if it was failed, you can send the request repeatedly.
In addition, if you have any idea or feedback about Azure Active Directory, you can submit them from here.