Don Airey

My feedback

  1. 1,020 votes
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)

    We’ll send you updates on this idea

    66 comments  ·  Azure Active Directory » B2C  ·  Flag idea as inappropriate…  ·  Admin →

    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.

    /Parakh


    Old message:
    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?

    Don Airey commented  · 

    Microsoft: Because of the cost and the fact that there is a workaround available, other features get prioritized over this one.

    Translation: Please evaluate Okta as we currently are not employing anyone competent enough to build this feature into our product.

    Don Airey supported this idea  · 
    Don Airey commented  · 

    For Role Based Authentication, you just need a group membership in order to map the group to a set of claims. So the answer to your question is: we just need what Azure AD does in the B2C endpoint.

    Don Airey commented  · 

    I had a colonoscopy last year without anesthesia. Digging through the B2C architecture to get my claims-based authentication working was a worse experience for me. First, there's no way to create a local user using an email address for the identity (that is, an email address not tied to any identity provider) in the portal . You need to create a separate application with CRUD privileges. Then you need to add the new user with a command line utility found in GIT. Then you need to go back to the portal to add them to a group, then you need to bake the credentials of this secondary application into your service in order to read the group affiliations of the users.

    It's not all pain, however. Once I got everything working, it's very slick to have a complete web service working out of a single Cloud Service with Authentication and SQL handled in the cloud.

Feedback and Knowledge Base