I am experimenting with using the Access Control Service in Azure. I have most of it working, I can log in using any of the providers but I'm having an issue with the claims against the WindowsLive provider. With the google provider I am able to get such useful information as the person's name and their e-mail address. I put similar claims in for WindowsLive but I get back the same value for every single claim. I've tried
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (I expected this to be gobbildygook)
http://schemas.xmlsoap.org/claims/EmailAddress
http://schemas.xmlsoap.org/claims/CommonName
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
each of these return something like :oULpbTv2AMylPasgUOsLZAHjaBYtxldrU+gg3aS5nI4=
Now I'm pretty sure that isn't my e-mail address because it wouldn't fit on my business card and I know it isn't my name because my mother isn't Welsh and wouldn't support me being named as if I were.
I followed the tutorials found at http://robbincremers.me/2012/02/22/using-windows-azure-access-control-service-to-provide-a-single-sign-on-experience-with-popular-identity-providers/ and http://msdn.microsoft.com/en-us/library/gg185914.aspx to get this set up.
Is there some way that I can get information other than an identifier out of WindowsLive? Maybe the issue is related to my not setting up an encryption certificate?
Edit: After some searching I found Are any other claims available from Windows Live ID via the ACS 2.0 identity provider? which suggests that my attempts to get more information out of WindowsLiveID is a hopeless quest. I will just prompt users for information when they log in for the first time.
The windows live provider doesn't give you anything other than a unique providerId. This is unique to your application and the user's windows live id. Google is a little better in that they give you the users name as well as their email.
The way I solved this is that on account creation in my application I just collect any information from the user that I need in addition to what is provided from the claims. So if they are using Google then i pre-populate their Email and name on my "Create Account" form. If they're using Windows then the form fields are just blank and they have to fill out the necessary info to finish creating their account. It works pretty well.
Related
Running into a bit of an odd issue. I assume it may be a setting somewhere?
Using the API integration for embedded forms. We have two brands, so I've made two users with the same roles. Their job is to be the sender for any embedded form for their respective brand. Their roles are both set as sender from the user settings tab.
support#brand.com
support#other-brand.com
Each user is in 2 groups, developers and their respective brand. Simply being part of developers will allow them to be assigned as the sender of any API templates. It's worth noting, these two users are identical to one another in setup, only difference being support email.
Using user 1, there are no issues, and everything works as intended. Using user 2 however, I get the error "consent required" when trying to get a JWT token?
I've gone through all and any settings I could find, but nothing seems to do what I need. Both users belong to the organization, so I'm simple confused.
Any help and direction is much appreciated.
The answer was I needed to claim the #brand URL the 2nd user was under, which had not been claimed via the application admin interface.
Consent is per user, you would need the second user to log in and navigate to the URL For consent.
If you are using the developer/sandbox/demo environment (not production) the URL you would want to set looks like this:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=<your IK>&redirect_uri=<some URL you defined for the IK>
Remember to define the redirect_uri in the Apps and Keys page in the settings page where you created the Integraiton Key and you should be good.
Hoping someone can shed some light on the following matter;
I got an Angular & .Net core Web API application that uses Azure B2C to authenticate users.
User accounts are created by the users themselves via the signin/signup custom policy or administrator can create accounts via the app using the Graph API.
Due to the requirements, the app uses usernames (as opposed to email addresses) to log into the application. So far I've managed to get everything working except for the following scenario:
When an account is created via the Graph API, the owner of that account cannot reset the account's password. The error is "An account could not be found for the provided user ID".
This isn't the case for accounts that get created via the custom signup policy so I did some comparison and found that for those account that get created via the Graph API, the Email is missing (which can be found under User -> Authentication Methods). I looked at populating that field, but it appears the "Mail" attribute is 'read only' (not sure if that's the right attribute anyway).
At the moment I'm having to manually set the email via Azure so those account's passwords can be reset by their owner if necessary. This is obviously not ideal and wanted to see if there is anyone that might have gotten around this issue, or a least get confirmation that this is indeed a limitation of the Graph API.
Thanks in advance for your help
So I managed to get this working using the approach outlined by Jas Suri. These are the steps that I went through
Created a custom attribute in my B2C tenant to hold the account email address
Included the custom attribute claim type (extension_emailAddress) as well as the strongAuthenticationEmailAddress in the TrustFrameworkBase.xml
Updated my apps's custom policies to include the technical profile for local account discovery. I basically just copied the necessary bits and pieces from here
Updated the local account discovery to perform the comparison against the extenstion_emailAddres instead of strongAuthenticationEmailAddress.
Added an extra step to the Sign up user journey so that the value in strongAuthenticationEmailAddress is copied to extension_emailAddress
Updated my Web API / Graph API "create user" function so that it sets the extension_appidguid_emailAddress
That's it. Now it doesn't matter how the account gets created, the email address will be stored in the extension attribute and the password reset will be able to find the account using that attribute.
happy to provide more details if anyone comes across this.
The problem is as you’ve identified, the Sign Up policy uses the strongAuthEmail attribute to store the verified email for a username based account. The Password reset policy will use this to verify the user owns the username. When creating the user with graph api, you can’t populate this field, it’s not exposed. The only option is to use a custom policy which stores this secure email in an extension attribute, and your graph api created users can then also target the same attribute to allow the stars to align.
Mail attribute is not the same as the Email under Authentication Methods, and currently there is no such graph api to set the Email value under Authentication Methods.
By the way, there is no need to create Azure AD B2C user for a user as users can sign up themselves.
I've downloaded the starter pack and performed all steps as mentioned in the tutorial. I can create accounts but if I log out and want to sign in again I always get the error invalid username or password. Can anyone share any pointers as debugging this is nearly impossible.
I've created several accounts already just to be sure the password was ok.
I've created the keycontainers
I've created the two applications that are needed in the custom policies (web app and native)
I've updated the extension file with the correct id's
yeah if you dont get your client IDS correct you cant log in and then it constantly reports as invalid credentials.
Double check that you are writing the object ids correctly.
Let me start by saying I really like Deployd. I want to use it in production, but I want to incorporate OAuth and social logins, so I installed the dpd-passport module. It works great, except for two little (big) problems:
When a user signs in via an OAuth provider (e.g. Facebook, Twitter, Github) a new user record is created...but if the same user clears their cookies or uses a different browser to log in, a new user record is created.
If I do something clever (read: hacky) and assign users with social logins an ID based on the socialAccount and socialAccountId (something unique but constant for each social account), someone could use the standard method of user creation to spoof a user by making a POST request to the /users endpoint if they knew that user's socialAccount and socialAccountId.
My question is: How can I A) prevent #1 from occurring, or B) disable the standard method of user creation without also preventing OAuth user creation?
Has anyone ever successfully used Deployd and dpd-passport in production? If so, I want to speak with you...
Thanks in advance!
First of all, I think you haven't added the custom fields per the docs.
https://www.npmjs.com/package/dpd-passport#requirements
I hadn't either, and observed the new user feature (because it couldn't lookup the response from the auth service to find the user from before). Adding these fields fixed it.
Also, there is a google group here:
https://groups.google.com/forum/#!forum/deployd-users
Hope that helps.
I have a WSS 3.0 site with FBA and a custom user management web part. To track user email address, I have been using the Email property of the MembershipUser object. I just realized today that if you go into People and Groups and look at the email address for a user, the email address is blank, and can be edited there independent of the MembershipUser value. It seems that the alerts system uses the email address that is stored in People and Groups.
I have not gotten into recoding yet because I want to make sure I'm not missing anything first. I assume I could switch from MembershipUser.Email and story my information in SPUser.Email instead. But I seem to remember that on a different project I used MembershipUser.Email with no problems and the alerts went out fine (although that was MOSS).
So I guess I have two questions:
Is there a way to tell People and Groups or the Alerts system to use MembershipUser.Email?
Is it best practice to use SPUser.Email for email storage, rather than MembershipUser.Email?
This post goes in-depth in getting SharePoint to sync the user profiles in your FBA store by naming all properties sharepoint should know about in the web.config and create those properties in your ProfileProvider. Not sure if it is what you are looking for exactly though. FBA user profile mapping does not work as clean as AD user profile mapping does out of the box.
Also, check out the User Profile Import Tool on CodePlex. It's for MOSS but might provide some pointers.