Identity Foundation Error

[jwanyeki]

I am running the ./run.sh command for the identity foundation but the script is completing with the following error:

Identity Foundation deployed with errors. Sometimes this is due to an error happening with the Azure Resource Manager. Try running the script once more to see if it continues past the point of failure.

I have run the script severally but am still getting the same error. Any help will be highly appreciated.

[1iveowl]

Thanks @jwanyeki for reaching out.

Can you share some more details? What does the log say? Is there a specific part that fails?

[jwanyeki]

I have tried the process 10 times today without success. The error message on the logs is still the same
cp: cannot stat '/asdk/src/Saas.Identity/Saas.IdentityProvider/deployment/config/certificate-policy.json': No such file or directory

[jwanyeki]

Hmmm. Strange. That should work fine.

Are you still asked to login when you run the script after running the Az command I mention above?

Yes. Am prompted for the login and the code

[1iveowl]

You should not be asked to login again. Could you try and uninstall az cli and install it again? It feels like a login issue.

I'm really sorry that you are having this issue. I need to look closer at the script again and maybe send you something to test.

Anyhow, it's 7:30pm here in my timezone and I'm not by my computer currently. I will get back to you.

[jwanyeki]

Thanks. let me try the workaround. My time is 2030hrs, Nairobi. I will keep trying for the next 5 hours just in case you have some more input. I really want to adopt this SDK in my SaaS Application.

[jwanyeki]

You should not be asked to login again. Could you try and uninstall az cli and install it again? It feels like a login issue.

I'm really sorry that you are having this issue. I need to look closer at the script again and maybe send you something to test.

Anyhow, it's 7:30pm here in my timezone and I'm not by my computer currently. I will get back to you.

I have reinstalled az cli and reinitialized the local files from the forked repository but the certificate-policy.json exception is still being generated.

[jwanyeki]

[jwanyeki]

Hello,

Thank you very much for your continued support. The bash /asdk/src/Saas.Identity/Saas.IdentityProvider/deployment/start.sh script line is at the tail of my run.sh and not start.sh. I have added a # right after bash, executed az login --tenant and then az account show and the tenant information was displayed as expected. See the script below where security sensitive details have been replaced with XX

{
"cloudName": "AzureCloud",
"homeTenantId": "XXX",
"id": "XXX",
"isDefault": true,
"managedByTenants": [],
"name": "XXX",
"state": "Enabled",
"tenantId": "XXX",
"user": {
"name": "XXX",
"type": "user"
}
}
Am still looking for a solution to the technical hitch

[1iveowl]

You are correct. I meant run.sh

Please don’t run az login —tenantfirst. The point is that this should not be necessary, since you already ran az loginoutside the container. The container should be able to “pull in” your credentials. If it’s not, then that is what is causing the the issue.

Could you please exit the container run it again and only run az account showand let me know what you see?

[1iveowl]

Btw. This is how the container get’s your existing az cli credentials: --volume "${HOME}/.azure/":/asdk/.azure:ro \.

You may want to check and see if you can access the directory ./asdk/.azure/ from inside the container. It should hold a number of the az cli config files.

[jwanyeki]

Hello @1iveowl . I concur. This seems to be an az-cli issue. I have executed the requested command but an being prompted to re-authenticate. What do you suggest I do. I had followed the cli-installation guidelines provided here.

[jwanyeki]

Btw. This is how the container get’s your existing az cli credentials: --volume "${HOME}/.azure/":/asdk/.azure:ro \.

You may want to check and see if you can access the directory ./asdk/.azure/ from inside the container. It should hold a number of the az cli config files.

Yes. The directory files are accessible on the running container.

[jwanyeki]

[jwanyeki]

Thanks @1iveowl . The issue was on the Azure-CLI configuration, and location settings on the config.json. I will share a small document tomorrow on the clarity needed when configuring CLI on WSL as well as location settings and why the respective documentation sections need improvement for a smoother deployment. I also faced a few challenges with GH_Token. The scripts work well though and many thanks to the team that build this.

[1iveowl]

Thanks @1iveowl . The issue was on the Azure-CLI configuration, and location settings on the config.json. I will share a small document tomorrow on the clarity needed when configuring CLI on WSL as well as location settings and why the respective documentation sections need improvement for a smoother deployment. I also faced a few challenges with GH_Token. The scripts work well though and many thanks to the team that build this.

Awesome! Can't wait to learn more about what you learned so that we can improve the documentation. Great work that you figured this out!

[1iveowl]

@jwanyeki

Hi James. If you don't have time to write a detailed document, feel free to dump the essential finding here and I'll be happy to write up the documentation changes needed.

[jwanyeki]

Hello @1iveowl . Thanks for the follow-up. Below are my power points for a smooth deployment which might not be clear from the documentation

1. The location specified on the initConfig section of the config.json file must be a valid name within the locations displayed once you run the command (az account list-locations --output table). This must be within the name column of the output and not the displayname column e.g francecentral is valid but using France Central will prevent the certificate-policy.json file from being generated.
2. Uninstall previous versions of CLI and follow the installation guide provided here. If you had installed the windows msi version of the az-cli previously while working with PowerShell, your container might be unable to pull az-cli credentials if proper configurations are not done within WSL. In my case I uninstalled all previous versions of az-cli and run(
   curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash) for the container to persist the credentials.
3. Uninstall all previous versions of gh cli before running the gh cli install command provided here . I was running on version 2.4 of gh cli that caused the deployment to generate GH_Token exceptions and running gh auth token command could not generate the authentication token required to complete the deployment. Remember to run gh --version to confirm your gh cli version before attempting to execute ./run.sh. The current stable version of gh cli which is yielding a seamless deployment is 2.29.0

[1iveowl]

This is brillant @jwanyeki! Thanks for the contribution. I will go and update the documentation with this right away!

[1iveowl]

The documentation enhancements have been implemented.