SCIM defects
The Azure AD SCIM client does not follow the SCIM Base URI properly.
As per, https://tools.ietf.org/html/rfc7644#section-1.3,
The resource relative paths (e.g. /Users) needs to be appended to the configured Base URI.
Azure AD is instead appending "/scim/Users" to the URI configured on the Provisioning tab of the app. If my SaaS application requires the tenant ID in the path (e.g. https://bla/scim/tenantID/), this is not possible with Azure's client.The Azure AD SCIM client doesn't implement a proper OAuth2 client. It simply asks for the OAuth bearer token to be provided in the configuration. This is no good since bearer tokens need to expire for security reasons. The SCIM client should instead implement the OAuth2 client credentials grant or password grant to a configurable OAuth2 token endpoint.
Peter Varga
shared this idea
The first issue is fixed as described here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-provisioning-config-problem-scim-compatibility
OAuth authorization code grant flow is now supported for new apps that want to be added to the Azure AD app gallery. You can request your app be added here – https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-app-gallery-listing
Work to support the code grant as well as client credentials on the non-gallery app is currently in our backlog. It’s intended to be done, but not yet funded.
In the meantime, the 1KB token limitation has been lifted.
13 comments
-
Anonymous
commented
And again still no news of the issue #2 ? TWO Years? Seriously?
-
Fabrice
commented
Still no news of the issue #2 ? Or maybe this is simply to motivate the registration of the app in the gallery.
-
Bissat Matthieu
commented
Hi, on my side issue #2 is problematic as well. Is there any timeline on when the "OAuth authorization code grant" feature will be deployed for non-gallery apps?
And what about the "OAuth client credentials grant"? The doc says it is in your backlog, any update?
Thanks,
Matthieu -
Charles Tandy
commented
Is there any update on when we can expect to be able to use code grant flow?
Having long lasting Bearer tokens is very problematic and introduces security risk.I also can't use the bearer tokens from my current OAuth provider because they are too large for the current storage limit: https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/application-provisioning-config-problem-storage-limit
This makes it impossible for me to integrate with Azure without switching OAuth providers.
-
Alexander Bergmann
commented
Ist there a possible date already when we can use code grant flow in custom SCIM App?
-
Anonymous
commented
When you will fix the second Issue? Its very difficult to use a bearer Token.
-
The feature for OAuth support is in progress. We are working on expanding support for it currently.
-
Anonymous
commented
Is there any update on issue #2? The lack of proper oauth or SAML support makes integrating to Azure AD very problematic at this time.
-
Aaron S.
commented
The first issue is fixed, the second issue is still outstanding. https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-provisioning-config-problem-scim-compatibility
-
Osman Ilyas
commented
#1 has definitely been fixed
#2 is still a problem
-
Arindam Laha
commented
Hi,
Is there any update on this topic? Azure AD SCIM is not implemented as per the RFC guidelines. -
B
commented
How can violating the SCIM2 RFC be a design decision?
How can it even work with any SCIM2 backend if it is requesting the wrong URIs?
-
Anonymous
commented
Regarding #1, indeed a very problematic behavior.
It violates section 3.2 in RFC 7644.
I am currently discussing this with Microsoft Tek support; their answer up to this point is that it is a by-design behavior...shlomi at anchi dot name