I am just learning Mobile Services. I've created a simple one which works fine locally. I published the mobile service to my Azure account. I then tried to access a method on it from the browser and I get a log in dialog. I figured out that I need to provide the application key generated by Azure as the password. Once I do this, it executes correctly. However, is there a way I can execute a method without providing a key? In other words, what if I wanted to expose one or more methods to everyone, without any authentication. How would I do this?
Yes, there is a way. There are four authentication levels in Windows Azure Mobile Services.
scripts and admins
authenticated users
users with application key
everyone
By default, the authentication level is set to "users with application key".
Depending on the backend you use, you either have to specify the auth level in the Management Portal in the data-tab (Javascript) or as a method attribute in your Controller-class (.NET) to "everyone".
Related
I'm struggling to correctly configure my app in the Azure portal. My application prompts for user permission every time it runs. The goal is to prompt an admin user ONE TIME to grant permissions to my app.
I'm writing a CONSOLE application to create a new task in Microsoft Planner by making API calls to the Microsoft Graph API.
I'm using delegated permissions for this so this application needs to take on the permissions of a user.
The good news is I've gotten this to work already.
What I need help with is configuring my app in Azure portal correctly.
Right now, every time I run the app, it prompts for consent. I'd like the app to ask an administrator to grant permissions to the app up front once and let the console app work without prompting users after that.
One issue I have is setting up the Redirect URI. The ONLY way I've gotten this to work so far is to set the URI to "urn:ietf:wg:oauth:2.0:oob".
As much as I've read about redirect URIs, you'd think I'd have this part figured out. I've tried using:
https://login.microsoftonline.com/{0} ({0} = tenant id
msal423d50b9-dfba-4c66-88f8-26c1432083e4://auth
https://login.microsoftonline.com/common/oauth2/nativeclient
https://login.live.com/oauth20_desktop.srf
When my console application runs, it directs the user to the login.microsoftonline.com and there I can choose a user, and then it asks me if I'd like to grant authority on behalf of my organization to all the permissions listed. I click the Accept button and it tells me that the Redirect URI does not match the one in my configuration.
Keeping in mind this is a console application, can someone please advise me as to how I should configure this to work correctly?
private static IAuthenticationProvider CreateAuthorizationProvider(string clientId, string authority, IEnumerable<string> scopes)
{
var clientApplication = new PublicClientApplication(clientId, authority);
return new MsalAuthenticationProvider(clientApplication, scopes.ToArray());
}
As you can see, the code is passing a client Id and authority. The authority in this case is where I'm passing the redirect URI. This is where I believe my problem is and where I could really use some help.
Every example out there is for a web app of some sort.
Am a bit confused about the One tap sign in that was announced by google earlier this year. Our application already users Credential Management API in Chrome, which essentially provides the user with login options based on the credentials that user has saved for our site on previous visit (passwords that are saved in chrome). When I read the documentation for One tap sign in, it promises to do the same thing, but using Google's client api id. Our application has its own ID provider with our own database of user name and passwords, from the documentation it looks like One Tap sign in does not support custom ID providers. Can anyone shed more light on this, why would I use one against the other?
Thanks
Karthik
I see two major differences:
One Tap is passwordless - it uses a token based login that never exposes the user's password. Chrome Credential Management API stores and retrieves actual passwords in Chrome's password store.
One Tap is purely web based - Chrome Credential Management API relies on Chrome's specific implementation. One Tap is a purely web based workflow so it will work across browsers.
One Tap is a much better long term login solution in my opinion. The Credential Management API is experimental and currently only supported in Chrome.
https://developer.mozilla.org/en-US/docs/Web/API/Credential_Management_API#Browser_compatibility
I lead product development at Google for the one-tap/auto sign-in library, we designed it such that the library includes the Credential Management API and extends to provide assistance in account creation, secure passwordless, and cross-browsers support.
In particular, if you make a request for existing credentials with code like this:
googleyolo.retrieve({
supportedAuthMethods: [
"https://accounts.google.com",
"googleyolo://id-and-password"
],
supportedIdTokenProviders: [
{ uri: "https://accounts.google.com", clientId: "CLIENT_ID" }
]
});
then any saved username/passwords from the Credential Management API will be returned (in browsers supporting the API) along with token data for Google Accounts. The one-tap/auto sign-in JavaScript library wraps the Credential Management API for credential retrieval.
Furthermore, the library provides a googleyolo.hint method to show an email selector for one-tap selection of a verified email address to assist in new account creation, or to link to an existing account, and then be auto signed-in next time with token instead of password, across all browsers, so long as the same Google Account is active.
I'd suggest using the one-tap/auto sign-in library and consuming tokens as well as passwords in order to get assisted sign-up, keep existing users signed-in automatically, and provide functionality even if the browser does not support the Credential Management API.
As for the question about using your own database of username / password, the hope with this library is you could implement the ability to create accounts and auto sign-in to these and existing accounts with an OpenID Connect ID tokens representing the user's identity. With the one-tap / auto sign-in UX, these are not only much more usable, but far more secure then passwords and mitigate creation of weak/re-used passwords. Please consider this or, even better, a hosted auth solution like Firebase Auth or Auth0 and include the one-tap UX in the frontend UI.
We have an on-premise website at the moment and I need to make it public, but require users to log in with their office 365 username and password.
My problem is that I've looked everywhere and can't seem to find an implementation for ubuntu servers.
I've also seen many instances of syncing office 365 accounts to the on-premise AD accounts, but not the opposite.
Ideally it should be implemented through Single Sign On.
You need to register your website as an Azure AD application, which will provide you with an app id and app secret. Your website will then need to implement the oauth 2.0 flow. Microsoft provides libraries for most platforms but if they don't have one for yours, everything is accessible through REST calls.
There are two most likely approaches to achieve this:
Configure SAML SSO in your application then use Azure AD as the IdP (as in Bernhard's comment). This will allow your application to gain information passed within the Saml token. You'll still need to present the site to the Internet via some sort of reverse proxy
Consider placing your website behind Azure App Proxy. This will allow you to publish the site over the Internet without having to open any firewall ports, and will allow you to use KCD to log users in without having to configure anything in your application, simply enabling Windows Integrated Authentication. This provides two very important benefits: 1) Unauthenticated visitors cannot hit the site at all, providing significant DDoS/attack protection, and; 2) No reverse proxy or other appliances are required, typically
I'd like to know if its worth investing time into developing an IdentityServer3 implementation that would work similarly to how Sharepoint allows for an initial Login using Integrated Windows Authentication, but then allow user to login as a different user with a prompt for credentials. Our hospital has many users where their primary workstation is set up as generic login. I'd like to use integrated Authentication, but allow these users on generic workstations to re-login as themselves.
From my research I think a logout page that actually invalidates the original token along with a secondary external Identity provider running without integrated Authentication is where I'm heading, but would like some validation that its feasible.
You would approach that problem differently with IdentityServer - on the login page you would give the user a choice. Either use integrated authentication or specify some username/password explicitly.
Logging out of identityserver would then also allow to switch identity if needed.
So yes this is possible.
We have an example that does built-in Windows authN (username/password is disabled - but you can re-enable by setting EnableLocalLogin to true here https://github.com/IdentityServer/IdentityServer3.Samples/blob/master/source/WebHost%20(Windows%20Auth%20All-in-One)/WebHost/Startup.cs#L36).
Curious what recommendations anyone has.
I have an existing asp.net forms application that does a Forms Authentication and has identity impersonate turned on.
The application has a link to a questionnaire that I would like to develop separately in an asp.net MVC application, but I don't want the users to click on the link and be prompted for a username and password, I would like them to be able seamless start filling out the questionnaire.
Is there a way to somehow transfer authentication from one .net app to another? I would like to be able to pass stuff like UserRole.
What's the best way to do this?
If you use the same MachineKey in both applications and the MVC application is on the same server, I think that it will reuse the auth cookie and simply consider them logged in. See this MSDN article on configuring the MachineKey, especially the section on sharing authentication tickets across applications. Note this assumes that both applications are on the same server. If they are on different servers then you'll need to investigate some other mechanisms -- say generating a single-use ticket for the URL that can be used by the remote system via a web call back to the originating server who the user is. It might not need to be a full-up implementation of a central authentication system, but along those lines. Just be sure that you're using SSL to encrypt the relevant bits to help avoid man-in-the-middle attacks.
Using Windows Identity Foundation (WIF) you can achieve Single Sign-On.
In WIF, a service called a Security Token Service (STS), issues a token with claims, which can be anything you want to declare about the authenticated user, for instance his roles. In your apps you can use the Page.User, Controller.Page or Thread.Current.Principal properties to check the User claims (though if you'll only be using role claims you can use the IsInRole method for simplicity).
You can easily create a STS using the tools for VS included in WIF's SDK. The Forms authentication will be done in the STS instead of in the Web Forms site and both sites should have a trust relationship with the STS.