I have a to-do app, where users can log in, I assign certain tickets to them, they can see only the tickets assigned to them, and they can mark them as done (this is a simplified version of a real app with about 300 users).
My current authentication set-up is a simple email/hashed password saved on the database. I have a list of users, in my tickets table I have assigned_to_id where I save user_id.
Now, if I want to migrate to Azure AD B2C (I can't use basic Azure AD Connect because my users are using their personal email, if I understand well I need to use Azure AD B2C), how will I know the id of the user to which I should assign it to? How do I know which tickets I should show to the authenticated user?
I find it a bit confusing when I don't get to manage this on my own db.
Do I need to change the assigned_to_email and compare the assigned email and authenticated email? When there is a new user, do I have to create it on Azure and on my db?
Related
To give our app permission to update a user's envelopes, they need to go through the OAuth flow and after that, we need their user id.
For my developer account and my demo account, I can find this under Settings > Integrations > Apps and keys. But my client, who has a paying DocuSign account, doesn't have that menu. Is there another way to find the user id?
Thanks!
After the user logs in via oauth, use the userinfo endpoint to obtain their user id and the account IDs they have access to. See https://developers.docusign.com/platform/auth/reference/user-info/
I have made a Blazor app, that authenticate users in my AzureAD, that works out of the box and are very smooth. Users are from different customers and are in a ADgroups for every customer, but use the same APP, and have roles from the App-setting in AzureAD.
Problem:
The customers have their own SQL with data and users must only see data from their own Azure-SQL, so I have a long list of SQL databases, one for each customer. When I validate a user, I can only get the AD-group-GUID from tokens, so how do I differentiate the SQL databases, for every customer?
My solution so far is to have a manually updated table with the customerID and AzureAD group GUID and use this to allow access to the users, to their data, but this seems to be a workaround.
Can some of you think of a better solution to this problem, where users must only access one of N* databases, allowed from a AzureAD group?
I am new to powerapps, and I need to create an app with AzureAD authentication. But I am confused by this authentication. Do I understand correctly that I don't have to implement user sign-up and login screens, because every user which will be added to AzureAD would be able to login to microsoft account and will have an access to my powerapp?
So, I don't have to write any code for user signup/login/forgot password?
But in the Internet I saw that some people use AzureAD.getUser() and Office365.User. When do I need it?
PowerApps is building enterprise apps for your organization staffs. This app has to be developed, published and shared to AD users, and users can sign-in using Active directory single sign-on.
You can invite/share with AD individuals, security group or O365 group. But not Distribution groups. You can share the app to all users by sharing with “Everyone”.
Even PowerApps can be shared with external users (guests) but they must be guest users of an Azure Active Directory tenant.
How to share a PowerApp?
Yes, no signup or login other than Microsoft AD login/challenge screen.
Those snippets will be used to get current logged in user details.
Everything #ArunVinoth said and to add a little more info about:
But in the Internet I saw that some people use AzureAD.getUser() and Office365.User. When do I need it?:
These are PowerApps connectors (API wrappers) that allow you to surface AD/O365 data within the app for your users.
Example:
You may have a way for users to lookup contact information for people within the org.
You would add the Office365Users connector to your application
Then execute the .SearchUser method from that connector to display contact info based on user input.
These connectors are not for authenticating to the app, but rather providing lookup capabilities for your users. Or automating these lookups for your app logic.
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'm seeking a method of automatically provisioning an ‘active’ Yammer user account for a new O365 user account (and existing ones, as a once off), without requiring the user to ‘click the Yammer tile’ or otherwise login to Yammer.
The default process (as articulated in this post) is:
The Office 365 admin creates a user in Office 365 (or Azure AD).
The user logs on to Office 365 using the identity provider that is configured for the tenant.
The user clicks the Yammer tile in the app launcher to go to Yammer.
A new Yammer user is created for the Office 365 user.
The user's profile properties from Azure Active Directory are automatically populated in the user's Yammer profile.
We're building an employee app, which currently displays company news. We wish to add social functionality, leveraging the Yammer platform, via the REST API. We have developed a solution to impersonate existing users and like/comment on behalf their behalf.
However, most employees are ‘unsophisticated’ blue-collar workers, and it is anticipated that they will not complete steps 2, 3 & 4 above to ‘create/activate’ their Yammer user account (the activation steps).
Methods considered or explored so far:
Using the REST API to create a new user – this creates a user in the ‘pending’ state, which remains pending until the activation steps are completed.
Using the Bulk Update Users to create new users from a CSV:
a) If a password is set, then a new ‘active’ user is successfully created (great!). However, that user account appears to be entirely disconnected from the corresponding O365 user account (meaning changes to user profile properties will not sync to/from Azure AD, passwords may be different, and users who are deleted/suspended in AAD will not sync to Yammer). These accounts are only linked if/when the activation steps are completed.
b) If a password is not set, then the new user is created in a ‘pending’ state, much the same as using the REST API.
Questions:
Is there any other way to create an 'active' user in Yammer, which is linked to the user’s O365 account?
Could a provider hosted app be used to impersonate a user and complete the activation steps on their behalf?
Not that it solves the problem, but does the REST API allow you to update a user’s state from 'pending' to 'active' (or create an 'active' user in the first place)?
Your steps about the default process are pretty acurate but I would add that once a user is created in AD users can simply go to Yammer.com (either on web or on iphone/android) and sign in through there. Iphone and Android use an Azure Authentication library that will find the users Office account.
Is there any other way to create an 'active' user in Yammer, which is linked to the user’s O365 account?
There isn't at this time.
Could a provider hosted app be used to impersonate a user and complete the activation steps on their behalf?
This isn't supported at this time.
Not that it solves the problem, but does the REST API allow you to update a user’s state from 'pending' to 'active' (or create an 'active' user in the first place)?
There is not an api for this.