I would like to consume third party identity provider in my application.
B2C provide a MSAL WebView authentication with pre-generated or custom page layout
(with username, password, and button for social providers).
like below
But I would like to create my own native button, that will open directly the web view on the specific identity provider.
Does Microsoft provide such flow without using the pre-generated or custom page layout,
but redirect instantly to the Identity provider?
If Microsoft does not, where can I suggest new feature, enhancement and vote for them?
Let me know,
Regards :)
Use domain_hint parameter. If you open your policy with &domain_hint=facebook.com it will go directly to the selected identity provider.
Doc ref: https://learn.microsoft.com/en-us/azure/active-directory-b2c/direct-signin?pivots=b2c-custom-policy#redirect-sign-in-to-a-social-provider
Related
I see in UseWsFederationAuthentication that multiple Claims Providers can be specified.
My question is at Challenge time how do I specify which provider to use?
This is a winforms website.
Thanks for any help.
By default, With single claim provider , ADFS will proceed with available claim provider without prompting the selection page.
If you have more than one claim provider, ADFS will show the claim providers in the home realm page. You can select the right provider based on the user identity.
You will be able to customize the Home Realm Page, please look at the document for more scenario.
I'm trying to authenticate my app users with their credentials used at the website
I managed to authenticate users via Xamarin.Auth to login via Google, Twitter... etc but could not figure out how to authenticate them via ASP.Net Identity provider.
any ideas or examples ?
Your problem is not a new one, and is one that will be easily fixed in the near future (see note below).
When you're authenticating with a provider like Google or Facebook, you're receiving a token that you can then use to send to the API. Unfortunately Asp.Net Identity does not do this out of the box. You can either configure your API to use JwtBearer tokens, or check out the Identity4 project along with their samples. Note that if you're using Asp.Net Identity you'll probably want a cross between Quickstart 6 and Quickstart 8 so that all of the necessary persistent stores are in your database.
NOTE: You might also want to follow the Templating Team's PR #700 which is adding token based auth in the new templates which will soon allow you to rapidly create new Api's with Token Based Authentication for your mobile apps.
I'm building a mobile application (that might also later become a web application). The server side is a ASP.NET MVC + Web API application and I'm thinking about ways how I could implement the service's user management and authentication.
How should I implement the registration/login screen in the app? Offer native app forms, that will send just API requests to the service or is it preferable to show a web browser component and display the website's login page and then extract a token after the user logs in? I see the first option is more user friendly, but the second one will let me change the login / registration page (like for example adding external authentication providers) without breaking older versions of the app.
My second question is regarding the external authentication providers. ASP.NET Identity has good support for them and it is quite possible to let users register using Facebook or some other OAuth2 provider. Does it make sense to add support for external authentication providers when I plan to expose the app's API publicly? Are there any reasons why that is not a good idea?
Your first option is best if you believe your users will trust you to manage their passwords. You make a secure call to your service, have the service produce a bearer token as the result. That would be an anonymous call. I used the answer from this question to get me going down that path:
Get IPrincipal from OAuth Bearer Token in OWIN
If your users are less likely to trust you with their credentials, then the web view and external provider is a good alternative. You would need to work with providers that support the "Implicit Grant Flow" since don't want to share the apps clientid and client secret on the mobile device. This approach involves using a web view to login in, and then capturing the token on the client uri fragment on the response. I think it is on a location header, but don't have a working example in front of me. Something like:
https://your.domain.com/#access_token = 8473987927394723943294
you would pass that token with each api call afterwards .
Good luck!
I am relatively new to uisng ADFS (in ASP.NET) which is what my company wants to use and just have a few basic questions about that:
Am I correct there is no explicit "Authorize" call you can do like with ASP.NET Membership Providers? Unless you on a domain it presents you with a login screen and once you enter credentials it does validation and returns back a token with claims information.
Can you configure some forms to allow anonymous access like you can do with Forms Authentication?
Thanks.
Yes, you can setup pages in your app that don't require authentication. It works exactly like you'd do with Forms Auth.
On #1: in a claims based model, your app relies on an external system to authenticate users and receives evidence that the user is valid in the form of a token. You can completely automate this (using WIF and config files), or you can explicitly trigger the authentication process. In any case, your app won't be responsible for validating legitimate users anymore. It is a responsibility that it delegates to the STS (e.g. ADFS). That's why apps are called "relying parties".
I'd suggest you read the first couple chapters of the A Guide to Claims based Identity for a better understanding of the underlying principles.
All our inhouse projects use Active Directory authentication and impersonation as this is the accepted security policy for the company.
I currently have a scenario where I need to store user profile information, and I would like to use the built-in Profile Providers which is standard in ASP.Net. I've previously used this happily with Forms Authentication, however I can't find any helpful information on how to implement this when using Windows Authentication.
Is there any way I can get just the Profile Provider working with Windows Authentication out of the box?
Will I be forced to create a custom profile provider?
The data will be stored in the database, not in Active Directory. However if the latter is possible some guidance would be appreciated.
Notes
I don't need to use the Role provider, this is handled by AD.
I am not sure if I need to implemented the AD Membership provider to get the Profile Provider to work.
you can just use the standard SqlProfileProvider. As username, use the Context.User.Identity.Name property. ASP.NET will create a user entry in it's standard tables himself to keep track of it. The role provider also works in combination with windows authentication. See this link for more information: http://weblogs.asp.net/scottgu/pages/Recipe_3A00_-Implementing-Role_2D00_Based-Security-with-ASP.NET-2.0-using-Windows-Authentication-and-SQL-Server.aspx
if you enable and configure the profile provider in the web.config, you can use it like this:
ProfileBase profile = ProfileBase.Create(Context.User.Identity.Name, true);
profile.SetPropertyValue("MyProfileProperty", propertyValue);
profile.Save();
Good luck!