I have an application which is sitting behind WAF (Web Application Firewall).
Application is using Microsoft Active Directory for authentication.
Here are the steps
User try to access the application using the browser.
WAF layers see that REQUEST is not authenticated, hence forward it to Azure Active Directory
AAD shows the login page and the user enters username/password/MFA
Now token from AAD send back to the browser and it will be sent to the backend application
Now question is,
How backend application verify this token? Does it need an outbound connection to AAD or will it talk to AAD through WAF and browser?
Do I need to have NSG rules (outbound ) to talk with AAD?
It depends on which auth flow you are using.
For Authorization code flow, your application would need to talk to AAD to redeem auth code for access token and refresh token via back channel. So, you would need to allow connection to AAD (login.microsoftonline.com).
For Implicit grant flow, it's browser which directly gets access token from AAD via front channel. So, in that case, you won't need whitelisting in backend WAF.
I have resolved the issue by using service tag feature in NSG. Backend application need to be able to reach AAD in order to validate the access token.
I have added outbound rule with Destination Service Tag Azure Active Directory as shown below.
Here is the link: https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview
Related
I have a .net core web API server that I connect to from a mobile application. The server creates an invoice on Xero and sends the user an email etc...
I have been using oAuth 1 with no issues, but now need to switch to oAuth 2. As there is no front end-user on the API server, can this still be accomplished?
All the documentation I read, seems to need a manual login to grant authorization and get an access token?
I was using the XeroApi settings in my appsettings.json file with a pfx certificate and a private app.
I am using the C# SDK
Thanks in advance :-)
You'll need a user from the Xero organisation to go through the OAuth2.0 flow at least once to retrieve an access token. If you request the offline_access scope during this flow, you'll receive a refresh token as well; this will enable you to refresh the access token from your web server on an ongoing basis, without user intervention.
So yep, you'll need a manual login at least once, but as long as you request & retain the refresh token from that initial flow, once should be enough.
I want to create an c#.net application that allows users who have logged in to company domain by their username/password can interact with Box.net without authentication (SSO). The app flows as the following image
Users login by their username/password to company network and call the application
Application sends requests to Box.net, then box asks ADFS 2.0 for authentication
Application provides ADFS the user credential, and then ADFS sends authentication result back to Box.net
Box returns token to application and application use the token to do other actions such as uploading file, deleting files.
app flow
My question is:
- How can I request Box.net for single sign on from my application
As I have followed this instruction but it does not work
Use SAML Single Sign-On to obtain OAuth access token or code for using Box.com API
- After obtaining the token from Box.net, how can I do actions to Box.net as uploading, deleting...
I do not see instructions on Box.net for single sign on integrations.
please give me your ideas?
The clue is in the title - "SSO to obtain OAuth".
ADFS 2.0 does not support OAuth.
You need to do this via SAML - refer Single Sign On (SSO) with Box: For Administrators.
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.
I inherited an existing .net web application. It is an external website that is used by external users and internal users. To login/authenticate internal users, it uses LDAP authentication. External users goes to a different DB.
My IT department wants to change the way internal users login. They do not want to allow an external server to be able to access the AD using LDAP. Is there a more secure method to access the AD from an external server? Or is that not recommended at all?
Also, is the design of the login flawed? Should internal and external users be logging in the same way? What is considered best practice for logging in users?
You could use ADFS (Active Directory Federation Services) for this.
This will require you to install an ADFS server inside of your network (so it can contact the AD).
The ADFS Server contains a web based STS (Security Token Service) to allow web pages to login using an AD account.
Basicly in a nutshell it will work as following:
Your user navigates to the external Web Application
The Web Application will redirect the user to the ADFS STS server.
ADFS STS Server will verify your credentials (either by using integrated security or a web based login box)
If the ADFS STS Server is happy abou the credentials it will then redirect the user back to the external Web Application with a login token as extra information. This token contains information about the user (can be configured). It is signed by the ADFS server (to ensure the information is authentic) and can optionally be encrypted.
The external web application extracts the token and tests the signature. If it is all correct the Web Application will grand the permissions that the user should have.
For information to set this up in an ASP.NET application you could refer to the following url:
http://blogs.msdn.com/b/alextch/archive/2011/06/27/building-a-test-claims-aware-asp-net-application-and-integrating-it-with-adfs-2-0-security-token-service-sts.aspx
We have the following setup for authenticating users. A wcf authentication service that is hosted as a windows service on a server machine. The client is a C# CAB based application that communicates with the authentication service and other services (auditing,..) as needed.
We want to give an option of using Active directory to logon to the application.
The steps that were proposed are as shown below.
Authentication service running on server
user opens application on client
machine and chooses login by AD.
application, uses the userName and
password to authenticate user
against AD.
application sends some token from
the authenticated user to the
authentication service, to get back
information about sql server and sql
db name.
authentication service uses token against Active Directory
and verifies that user is logged on
and authenticated and returns back the required sql information.
Are steps 4 & 5 possible without the client app needing to send the username and password to the server for authenticating against AD? I want to avoid as much as possible sending passwords on the network.
You can't do that with AD and a client only, you need to involve a service in the authentication mechanism. If I were you, I'd send the username and password to the authentication service, the client shouldn't talk to the AD directly at all. And if you need some SSO, you can create a token in the authentication service. AD doesn't issue tokens, only you can, or another, more sophisticated service, like ADFS.