I'm new to azure (used to "default" ASP.NET apps) and giving it some tries I learned that:
a.) it is very easy to add mobile logins (using FaceBook, Twitter, MS-Account...)
b.) that I can't see any database storing this data (user IDs an so)
My needs are the following:
Enable users of a Win10 Universal / Mobile app to login with FB,... (works so far)
use these users (via ID or so) to assign custom database entries to them (profile or so)
assign (via some kind of management interface) the user to a role (for permissions)
merge different logins (let the same user login with different providers=
To explain this imagine a forum (driven by apps (UWP, Android, ...)):
The user logs in via Facebook.
After (example) 10 moderated posts he will be able to write posts without moderation. (assign to role)
Users can be manually added to roles (moderators)
Last not least if the preferred service is not available (some corporate networks for an example restrict Facebook access) - the user shall be able to use (for an example) Google to login with "HIS account".
I understand that "merging" may need to be done while both providers are available.
Something like - "you are logged in with FB - to you want to add Google login to your account - if yes pleas additionally login with Google now while your are logged in with FB...
Two extra points:
1. I don't want to have "username / password" (only social logins)
2. I want to store the users email (for notification purposes)
--used from the social provider if available - or manually entered
Is this possible with "Azure Mobile" or would it be better to create a "Web App" and add (somehow) add "Mobile capabilities" (login, push notifications..) to it?
Yes, you can absolutely do this. The token information (which is equivalent to the claims that you request when you set up the authentication within the Authentication / Authorization Settings blade in the Azure Portal) is available on the /.auth/me endpoint of your app. It's also available internally - for ASP.NET, that would be the MobileAppUser class. This is the IPrincipal for the request given an ASP.NET TableController decorated with the [Authorize] decorator.
You can adjust the information stored by the table controller. There is some sample code commented out of the FieldEngineer sample on GitHub for this.
Related
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 have a running website, where users already have accounts. And I am trying to create a Google Assistant agent, accessible on Android, to help users access their information.
My issue is that I can't detect returning users on Android Smartphones, each time they have to sign in.
I tried Anonymous User Identity, but it is soon to be deprecated.
Is there an other way to keep track of users?Using some kind of userId that I can store, so I can make "my own Acount Linking" linking the person/Smartphone with already existing user accounts.
There are a few angles to your question.
Is there any way to keep track of users?
Yes... but...
You can store a userId that you generate in the user storage area. You do need to treat this like you would a cookie, so some jurisdictions might impose restrictions on this, but this is one approach to moving from the anonymous ID that is being turned off soon.
But...
How do I let them log into my service through the Action?
That is the problem. The General Policies states the following limitation for collecting user data:
Authentication Data
(including passwords, PINs, and answers to security questions)
Don't collect authentication data via the conversational interface (text or speech).
After a user's account has been linked, PINs or passwords may be used as part of a second verification process.
So you need to use Account Linking to connect to the existing account on your service.
How can I do Account Linking if I don't require Google Sign-In?
You can still use Google Sign-In for Assistant if it will (or may) provide the information as part of the profile that match what you have. So it doesn't need to use the same account - just have the same email (for example).
But that still may not be enough.
For other cases, you can look into setting things up to work with an OAuth server that you control.
So why use Google Sign-In if I setup an OAuth server that uses Google Sign-In?
Google Sign-In is good for a more streamlined flow, if you can use it. It can be done completely with voice, such as with a smart speaker, instead of requiring the user to go to a phone to complete the login. So if you have the user's email address in your account system, and you also get this from Google Sign In, then you can connect the two accounts.
In some cases, such as if the user is expected to have logged into the account on your website first, they won't even need to do that. If both the voice client and web client use the same Google project, then authentication will take place automatically.
I wish to add Social Login feature to a Shopify store that I am building. (I'm using the professional plan.)
I explored a few of the available social-login apps on the Shopify App Store. Upon studying closely as to how they actually work - I have come to the following understanding of the general scheme being followed by all of them.
The Shopify shop owner sets up a social app (e.g. Facebook app) with their store identity, but configures the Callback-URL/Redirect-URL to one supplied by the App author (i.e. pointing to their infrastructure).
Upon successful login by a shop customer on the social platform (via a link/button inserted on the shop login page), the request gets redirected to the App.
The App retrieves the user's email address from the their social profile (that they now have access to).
They then lookup their own database to see if this is an existing customer. If so they go directly to step 7 below.
If it's a new customer, they use Shopify API to create a new 'customer' on the target Shopify store. They set the customer up with a randomly generated password.
At the same time they also make an entry of this customer account (email + generated password) in their own database.
They then redirect the request back to the Shopify store's login page but this time with the customer's email address (retrieved from social platform) and their password (from the App's own database) included as part of the data that comes back to the users browser as part of loading the login page.
Then the App's javascript embedded on the shop login page uses the customer email address and password to programmatically submit the login form - thus establishing a valid customer session on the Shopify shop.
My questions are as follows:
Has someone else also looked closely in to this, and thus can validate if my above understanding is correct or not?
If it is correct - is this the only way to achieve social login on Shopify (without using Shopify Plus/Enterprise plan)?
I am trying to understand if this indeed is the only way, because I strongly feel that this method is not at all secure. And thus I'd rather not use this method; or if I just have to - then I'd rather write my own (private) app for this so that at least I am in control of the security of the app/database that holds sensitive users credentials.
Would appreciate any help/thoughts I can get with this, please.
If you are rolling your own you probably want to look at Multipass. It would be the thing to use if you can set up another web service that handles the trusted partner registration process.
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.