Tip/Trick to be aware of when creating SSO between IAS/AAD

[wombling]

Hi,

was following this guide the other day with a customer and we had an issue, which was caused by the customer creating an inactive signing certificate:

The IAS used the inactive cert from the metadata rather than using the active one - which caused the SSO not to work. Was wondering if some sort of hint might be added in the documentation to help others in the future.

Thanks,

Chris

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 76e64689-b302-894f-08b4-60e9a037afdb
• Version Independent ID: 1d5e1344-a63b-7592-56f6-d35a78cafcc8
• Content: Tutorial: Azure Active Directory integration with SAP Cloud Platform Identity Authentication
• Content Source: articles/active-directory/saas-apps/sap-hana-cloud-platform-identity-authentication-tutorial.md
• Service: active-directory
• Sub-service: saas-app-tutorial
• GitHub Login: @jeevansd
• Microsoft Alias: jeedes

[HarshitaSingh-MSFT]

Hello @wombling , thanks for taking time to share your valuable feedback! We are taking a look into this and will get back to you soon.

[wombling]

My other thought is that this is a bug in the tooling from AAD and inactive signing certificates should not be included in the downloaded metadata. There isn't anything in the metadata that identifies them as inactive, so is quite confusing for any systems that are trying to interpret the metadata.

[shashishailaj]

@wombling That's a great thought . Let me check this internally and I will let you know further if we can have this change in metadata or there is some other explanation for the same.

[wombling]

@shashishailaj did you hear anything back from product team? Is this a bug that will be rectified?

[jeevansd]

@wombling This is not a bug but it is in this way by design. When you are adding a new application from new design of Azure AD app gallery then you need to populate the URLs first. Once the URLs are populated then the certificate will be created and that will be set to Active. If you are trying to create a new certificate directly then you need to manually activate the certificate. So there are two steps here. 1. Create a new certificate 2. Activate a new certificate.

But if you populate the URLs and click on the Save button then both these actions will happen automatically. Can you please try that?

This is been done in this way so that we dont directly generate the certificate for every app by default and occupy the space when the customer just wanted to know what is needed for the app to be configured. When they are actually configuring the app with right URLs then at that time we will generate and activate the certificate for the app.

[wombling]

Hi @jeevansd,

So it's by design that the exported metadata can include inactive certificates? That doesn't make sense.

It makes sense that a user could have inactive certs, and I agree, if they do everything in the right order then they wouldn't have any. But if they do, you're saying it is correct that the metadata should include that inactive certs?

If this is the case, then whilst I think this crazy, I would then fall back to my original request: could the documentation be updated to warn customers that if there are any inactive certs, the exported data will not work with IAS

[wombling]

Oops pressed wrong button!

[jeevansd]

@wombling We are adding inactive certificates in the Application Metadata. This is majorly used by our customers. Consider a scenario where customer has already build the SSO trust and it is running properly but in few days the certificate is going to expire. Then they create a new certificate in Azure AD and provide the new metadata to the vendor. Vendor look at the new inactive certificate from the file and configure it on their side. Then the vendor and customer get on the call and then they activate the certificate from Azure AD side and then vendor also set this new certificate for SAML trust. That is why we are including this inactive certificate in the metadata file. This is true for any app and not only for this SAP app.

Ideally we want ISV to able to configure all the certificates which we are providing but most of the applications does not support this model and that is why they have to do this dance.

[jeevansd]

please-close

[wombling]

Hi,

Could you please reopen this issue so it can be used to track the update to the documentation that then informs customers that this is the case and to be aware of it?

Thanks,

Chris

[wombling]

@jeevansd @shashishailaj can we please reopen this ticket to consider updating the documentation to help people that get stuck when connecting their systems to SAP instances because of this "feature" of AAD metadata exports?

Thanks,

Chris

[jeevansd]

@wombling This can happen with any other app. Customers can create multiple certificates in Azure AD and then all of them can be Inactive. To correctly roll this out they have to make sure that only one active certificate is there.

[wombling]

@jeevansd that's fine! I understand that you don't want to change the functionality of the export of the metadata so that you can handle exporting multiple certificates (including inactive ones.) I see the reason behind that.

However, this specific documentation is about linking to SAP Cloud Identity Services, which do not support the inactive certificates and cause a problem if you export the metadata that includes inactive certificates and import it into SAP Cloud Identity Services.

So could we please think about putting some sort of warning in the documentation "Hey - make sure that you don't have any inactive certificates configured because SAP IAS doesn't know what to do with them and your SSO won't work." or similar gist.

?

The request to put something in the doco to warn people that this issue might occur is why I originally raised the issue.

I hope that makes sense!

Cheers, Chris