I'm a bit confused regarding the authentication/authorization setting on the settings blade for an Web/Api App in Azure.
If I enable Azure AD authentication via the portal.
Is there any way to get hold of user information in the actual service then?
I know there is the Bearer security header, but can I extract any useful information from that?
Or is the authentication/authorization setting acting only as a proxy before the call to the service. that is, it requires valid AD credentials, but the service never have to deal with any of the details around it?
What would be the main differences between using that setting vs. creating an Web/Api App that uses Asp.NET authentication via code. e.g. its possible to set that up using the standard ASp.NET templates.
In those templates you get an OWIN app that uses an Azure AD authentication provider.
If I use the latter, is there any benefit from the authentication/authorization setting? or can I simply ignore that if the App itself has an authentication provider?
Using the authentication in the portal allows you to get some very rudimentary information about the logged-on user via the header "X-MS-CLIENT-PRINCIPAL-NAME", and you also have access to whatever claims are passed in. There's a good example here: Websites-Authentication-Authorization
Related
I am currently building an api along side our external app developers. I have read that the Authorization Flow with PKCE is definitely what we need for this set up however I am looking for some more detailed advice.
Our existing api uses the implicit flow and the app sends credentials + secret etc to the /Token endpoint in the api this then looks up the passed in data and compares with our users table. If that passes an Access Token is returned to the app.
With this new flow I have the following questions.....
Do I have to use Okta Portal/Dashboard and set up the api there?
Do all app users have to be stored in Okta dashboard? We usually manage our own users table where we add users from a custom tool. However I am presuming when using Okta our custom tool would need to call Okta api endpoint and register the user from there and then get and store the users Okta ID in our own table. **Does anyone have an example of how I do this from a C# Wpf application?
Do I then need to request the Redirect URL's from the App developer and set them up as a Native App in Okta dashboard. Presuming I need to give them some set values to hold their end to allow them to call Okta at authorization.
OpenID????? do I need this if so how and where does this get implemented?
I have read through so many tutorials but just havent quite found the exact fit yet.
Many thanks
You will need to access Okta admin console to register a client application. Once done, you can use Okta OIDC API's: https://developer.okta.com/docs/reference/api/oidc/.
You can use Okta SDK's to simplify the development process. Ex: https://github.com/okta/okta-oidc-ios
If Okta is going to be the authorization server, users and their credentials will need to exist in Okta
When you create a native App in Okta admin console, you will need to provide the redirect URI's that will be whitelisted
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. When you create a native application in Okta, will be a OIDC application.
Is there a way to use the native WindowsIdentity/WindowsPrincipal inside of a C# application running on a corporate domain to be able to request a SAML token from the domain's ADFS server so that the C# application can then make subsequent calls to WS-Federation calls in a service provider that has been federated with the ADFS server?
Seems like we would use WIF to contact the ADFS server to get a token. Is there a way to supply a Kerberos ticket to the WIF, rather than using a username/password?
Looking at WindowsIdentity.GetCurrent() I can see that the user is logged in using kerberos, but don't see how to configure the WIF call to ADFS to use kerberos to automatically get a SAML token without a username/password set of credentials.
Does https://blogs.msdn.microsoft.com/alikl/2011/09/30/how-to-use-ad-fs-endpoints-when-developing-claims-aware-wcf-services-using-wif/ help?
You should make sure you have an endpoint enabled that can do windows integrated auth via kerberos enabled. Something like /adfs/services/trust/2005/windowstransport or /adfs/services/trust/13/windowstransport . You can check that via parsing the /adfs/services/trust/mex endpoint. Occasionally some of these endpoints are disabled by a sysadmin.
Using a kerberos ticket as the credential for the endpoint means your app needs to be running on corpnet with access to domain controllers so it can obtain a ticket for AD FS. If the app use is not required outside corpnet this might be OK for you. Else you need to consider how the app behaves/authenticates inside and outside corpnet.
Have a look at https://www.microsoft.com/en-gb/download/details.aspx?id=4451 for samples but they'll need modifying based on version of WIF you plan to use as outlined in https://learn.microsoft.com/en-us/dotnet/framework/security/guidelines-for-migrating-an-application-built-using-wif-3-5-to-wif-4-5
Lastly you should consider if its possible to use OpenID Connect and OAuth2.0 instead of WS-Federation/WS-Trust in your scenario. If yes, you should review the information at https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-scenarios-for-developers
I am working on an ASP.NET MVC application that uses Azure AD auth out-of-the-box.
What I want to do is define custom roles for certain users. For example, mark JohnDoe#contoso as a "Portal Admin" or SarahJones#contoso as a "Site Manager" - I want to do that without messing with AD roles, since I don't have full access to the AD internals.
I am fine deploying a custom DB to contain the roles. Is there a generic solution for this or do I have to implement my custom verification layer?
Update 1: I can deploy a custom role provider and connect it to a different DB, but am wondering if there is a more straightforward way to do this.
If you use Azure Web Apps, which supports ASP.NET MVC then you can use the Azure Active Directory authentication mechanism. Here is a blog post describing how to set it up:
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-active-directory-authentication/
Once you have that, auth will be enabled for your app and you can configure the AAD app in the portal. See this blog post for more details:
http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
To modify the permission levels, you should be able to use role claims. See this example for guidance:
https://github.com/Azure-Samples/active-directory-dotnet-webapp-roleclaims
Accessing the manifest:
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.
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.