We are working to support SP-initiated SSO as well. However, we don’t have timing on when it would available to customers.
@Parakh, I don't think you understand... We're not asking for AAD B2C to support "Talking to a SAML2. IdP", we're asking for AAD B2C to be the SAML2 IdP for our AAD B2C local accounts.
Due to various technical limitations, the first iteration of the customer-owned domains functionality will not be available for a few more months. We will provide an update as soon as we can get a more specific ETA.
Please provide an update. We're coming up on 2 years since your last update, which indicated the functionality would be available in "a few more months"...
We have started working on this feature and hope to have another update by Oct 2018.
Good grief.... B2C is such a $h!@ show.
This is currently not on our roadmap. You can retrieve this value by making a call through the Graph API. If this is needed for your scenarios, please continue voting and we will review at a later date.
We definitely recognize the popularity of this feature, and we discuss it constantly during the planning phases. However there are certain technical limitations in the system that add a large amount of development cost. Because of the cost and the fact that there is a workaround available, other features get prioritized over this one.
That being said, please keep voting for it. The popularity of the feature does help bring it up and makes us reconsider every time.
Apologies for the delay.
We’re doing some research both on the specifics of this ask as well as what it would take to support this.
Is the ask here to do the same thing that regular Azure AD does (see: https://blogs.technet.microsoft.com/enterprisemobility/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles/) or is are there different requirements around this for Azure AD B2C?
What is this "workaround" that you refer to? This seems like such basic "minimum viable product" functionality... you must really have a mess of legacy code on your hands here. I'll continue to use AWS Cognito, Okta, Auth0 and other more mature solutions, and recommend that my customers and colleagues do the same... Microsoft probably doesn't really care that we use other solutions anyway, as is evident from the age and popularity of this request.
this feature is in public preview now. https://docs.microsoft.com/en-us/graph/api/resources/trustframeworkpolicy?view=graph-rest-beta.
We are working on managing policy keys programmatically.
We have restarted work on this feature. However, we don’t have a date for public preview yet.
Currently, you can use “App Registration” blade in the Azure Portal (outside of the Azure AD B2C blades) to register an apps that define application permission and the register apps that use client credentials to request these. The caveat is that this is done using the same mechanism that you’d use in regular Azure AD.
Ideally we’d have a first class experience for this in the Azure AD B2C blades or at least have an Azure doc that walks you through the experience I just summarized, so I’m leaving this feature ask open.
It would be great if you guys can add comments with your feedback. What scenarios areyou trying to achieve? Does the approach above help you achieve what you want to achieve? Does the experience to do so work for you guys and if not, what would you like to see?
At this point our recommendation is to move resources into a new Resource Group with the new name.