How does one go about tying in AD authentication to an existing Web API? I've attempted to do this with Azure but Azure doesn't play nice with Web APIs. The constant redirects are a nightmare. Is there some way I can set it up to just hit a local AD sever, authenticate the user, and get back a token? It seems like it should be fairly simple but I'm finding no information on this.
You will always be redirected if you're using Azure AD. You shouldn't be able to do this locally to my knowledge.
Related
I have access to my Azure AD Portal. I also have an external ASP.NET application which is accessing the Microsoft Graph API. For this purpose I add an App Registration which give me an Application ID and Key to be able to configure my ASP.NET application to authenticate itself against the Graph API.
I need the my ASP.NET application to read groups out of Azure AD. I can authenticate successfully but I get an error saying that I have not enough privileges. Then I go back to the Azure Ad Portal and add permissions to the App Registration I added. This works ok so in the end I have the Graph API response on my ASP.NET application.
Now it comes the issue. I selected too many permissions so I want to use the smallest set of permissions that are necessary for my ASP. So I go the Azure Portal AD again and remove some of the permissions. When I test my app again, I still receive the groups even if I have no permissions selected.
I think this is an issue. Or there's some kind of delay? I don't think so because when the API is working and has the proper permissions I can add a group in Azure AD Portal and instantly see it in my ASP.NET application.
This issue is specially annoying because you can't really test the permissions your app needs.
Thanks.
I am looking at adding custom authentication to my existing Xamarin.Forms app through Azure Mobile Services. Currently, my app authenticates itself against an existing WebAPI but the authentication isn't secure and I don't really want to start trying to create my own secure authentication process for production. I thought that Azure Mobile Services would be a good way of being able to keep the custom authentication side of my app (authentication against a current identity provider isn't an option) however I already have all the storage etc set up in an existing SQL database by sending it to the WebAPI first and then saving details.
I guess my question is: Is it possible to set up Azure Mobile Services with my current WebAPI acting as a kind of middleman? The basic workflow would include my app sending the log in details to the WebAPI, the WebAPI passing these on to Azure Mobile Services for authentication and then returning the response including token to the app after being stored on the WebAPI side.
The reason I thought that Azure Mobile Services would be a good choice was because it also provides support for push notifications as well as the custom authentication side of things.
Thanks.
Take a look at the following for custom authentication: https://adrianhall.github.io/develop-mobile-apps-with-csharp-and-azure/chapter2/custom/
Short version - yes, it is possible. You create a custom WebAPI that mints a ZUMO token within your Azure Mobile Apps SDK Within that minting process, you can check the users credentials (either a token, remote API or whatever) any way you want.
I am not sure if that is possible. You are trying authenticate through two different application. It might be possible to write the mobile service client login code in your web API app to use authentication from Mobile Service app and get the token back. But then you still have to manage the user sessions between your Xamarin app and web api app, cross origin stuff and etc,
Since mobile service app really is a web api wrapped with some extra functionality, have you considered moving your web api app to mobile service? That might be easier in my opinion.
Yes, this is possible.
In our app the user is able to register and to login with twitter and Facebook but with own email + pw, too.
In wams we sync the social account and "our" account (stored in the db).
Have a look at ClaimsIdentity and Microsoft.WindowsAzure.Mobile.Service.Security IServiceTokenHandler to implement custom authentication and returning a custom token.
I am just starting out with a windows azure mobile services .net backend, and am running into so many headaches as a new programmer. I have gone into my azure mobile services account and downloaded the todoitems demo app (c# for .net backend). I then followed the tutorials regarding adding facebook authentication, but I am absolutely not pleased by this method, as it shuts down the app for a few seconds. As such, I set out determined to create a custom authentication login page which ties to my mobile backend.
I found this article and thought, "Great!" only to realize that I had no clue how to catch a user created account from a textbox and to pass it along to the public class RegistrationRequest. The example at the end of the link shows how to connect to a local machine - but I want it to connect to my actual database at the following location: https://mycustomapp.azure-mobile.net, return a token, and continueon.
What is frustrating is that I am able to obtain a facebook authentication token, as well as user information. BUT, I have no idea how to generate a windows azure mobile auth token so that the client may write/retrieve data from my azure table.
Essentially my question is this - using the above link, how in the world may I take a user's username and password from a textbox, run it through the RegistrationRequest, and not have to pop advil on this? Do I need to pass my facebook token? I assume not?
I am also not using a facebook SDK or anything like that - simply put, I am using the above site's code trying to get an auth token from my azure mobile services, despite having one from facebook already, to authenticate a user against my azure mobile services data table.
If you already have a FB token, the easiest way to login to your mobile service is by using the FB token, then you don't need to make a custom UI/etc.
This can be done by calling
var token = new JObject();
token.Add("access_token", "access_token_value");
await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token);
see: http://azure.microsoft.com/en-us/documentation/articles/mobile-services-windows-dotnet-how-to-use-client-library/#authentication, Client Flow for more
if you want to login to your service with a Facebook account, you do not need to implement a custom authentication and to capture user name and password in your own textbox controls.
You should be able to use MobileServiceClient.LoginAsync() and pass as parameters the provider that you want to use. Check this article fro more information.
Is there a mechanism in Azure AD to have a completely headless authentication? Most likely this would mean (in my mind) that the server running the API would have a perpetual authentication session to Azure.
If the purpose matters... We have a need to expose our thumbnailImage attribute from AD and I just need to make it so that the server doesn't care who requests the image. So basically we will have https://domain.com/api/Image/userid and the api will return an Image object (image/jpeg). I have this functioning internally and now I'm just migrating to Azure.
I found this question... I just want to confirm two things...
Daemon or Server Application to Web API is the method I should be looking at
Using this method will function as I'm expecting... a.k.a. WebAPI can access that attribute and use it like I currently use it while inside our internal domain.
Indeed. Azure AD supports the client credential OAuth flow. Yes, you are looking at the right help topic. The corresponding sample application is here: https://github.com/AzureADSamples/Daemon-DotNet.
If you haven't already, use Azure management portal to register your WebAPI as an application in your Azure AD directory and add a client secret (under the section named 'key' in the 'configure' tab of the 'application'). This key will be used as the client credential.
To configure permissions for your WebAPI to be able to call Graph API using client credential flow token, go to the application tab in the Azure Portal, under Azure AD and in the section titled 'Permissions to other applications', add an 'Application Permission' to 'Windows Azure Active Directory' to 'Read directory data'.
What you refer to as perpetual authentication session is basically your WebAPI caching the access token to Graph, and getting a new access token (using client credential flow) when the current access token is about to expire.
Hope this helps.
There is a requirement to implement Single Sign On (SSO) in our website so that users accessing it from the intranet won't have to type in their credentials.
The problem here is that the website is going to be hosted on the internet, on a remote server.
Is there some way this can be done?
--EDIT--
I looked at following link:
http://en.wikipedia.org/wiki/Active_Directory_Federation_Services
And the example scenario that is mentioned in there is exactly what we require.
Here is the detailed explanation on the situation:
There is an Active Directory Domain Controller that is used to authenticate users in the intranet.
Once the user logs into the machine, and opens up the remote website, the website should somehow verify that the user is already logged into the intranet using AD credentials and automatically allow access to the website.
Also, the website is supposed to be getting a Security Token that can be used to authenticate the user.
Of course, for example, Microsoft's way of doing that for connecting Office365 to your Intranet is called Active Directory Federation Services.
It is (as most single sign on solutions) not entirely straight forward, and it assumes a domain on your intranet, but since Office365 uses it, it is and will most likely continue to be well supported in the future.
It's just a matter of integrating your web app with the authentication provider that you are using for SSO. The details are going to vary dramatically if your using OAuth vs. Shibboleth vs. ADFS vs. etc, so there really isn't enough information in your question to give a helpful answer.