I am currently using Auth0 for the offline authentication with downloading the token and validating the user against it. I am now looking to migrate to the Azure Active Directory - just want to double check if they have anything to support my existing process.
How long do you remain offline? Access tokens in Azure AD have a validity time of one hour and are automatically cached. Technically you could relax the expiration check if you want them to last longer, although that's usually not recommended.
Related
We have created a vb.net web app, it is secured with Azure AD easy auth.
The custom token policy has been created to log the user out after 20 minutes of inactivity, but the user always remains logged in for 8 hours.
Azure support have advised that this is because of the session cookie used when using easy auth over-riding the token policy. They also advise this cannot be changed from 8 hours which is far too long for a web app containing sensitive data.
Has anyone come across this or know of a workaround? As easy auth is “code-less” there seems to be nothing I can do in my project to affect this.
I think your Azure Support contact recently asked me about this case. Unfortunately the cookie lifetime is hard-coded at 8 hours. We can add support for making this configurable or to have it match the Azure AD token lifetime, but unfortunately it would take some time before such a change would be able to reach production.
When pushing a website update to Azure does the app pool reset? What effects does this have to a user that is signed into the site? Would the user get signed out?
When pushing a website update to Azure does the app pool reset?
Yes. You can check this in the Kudu Debug Console, under Process Explorer. Note how the PID of your application changes.
What effects does this have to a user that is signed into the site? Would the user get signed out?
Signing in with Azure AD (i'm assuming since you don't mention an IdP) is heavily dependant on your token cache strategy:
Assuming you're only using a memory cache for ADAL/MSAL and your app pool restarts —
In this case, the STS and ASP.NET cookie are still in the browser session, your code needs to check the cache and if it looks like a fresh cache, redirect user to STS (Challenge() in ASP.NET). This will be seamless and won't require typing in credentials since the STS cookie was never gone.
If the user session state is also stored in memory (the default for ASP.NET), then you'll lose the user's session state as well (if that holds a shopping cart, you have bigger problems to worry about).
The sensible thing to do is to move to a persistent token cache and a persistent user session store as well. Redis cache is a good choice. SQL is fine too, probably a bit much.
Is it possible to update expiry time of shared access policy of blob container through Azure portal?
Is it possible to set indefinite expiry time for shared access policy? I have an application which has html editor where users upload images to Azure blob storage. So they can upload images and see them through generated uri. I used shared access policy with READ permission so that users can see images inside html? Is it good practice to set indefinite expiry time of shared access policy with READ permission?
I don't want my images to be public, I just want authenticated users to be able to see the images. I don't understand advantage of using SAS in my case as any user having SAS can see image (for example my friend who receives image uri with sas). So, is there any advantage? Can anyone explain me this?
Is it possible to update expiry time of shared access policy of blob
container through Azure portal?
As of today, it is not possible to manage shared access policies on the blob container using Azure Portal. You would need to use some other tools or write code to do so.
Is it possible to set indefinite expiry time for shared access policy?
You can create a shared access policy without specifying an expiry time. What that means is that you would need to specify an expiry time when creating a shared access signature. What you could do (though it is not recommended - more on this below) is use something like 31st December 9999 as expiry date for shared access policy.
Is it good practice to set indefinite expiry time of shared access
policy with READ permission?
What is recommended is that you set expiry time to an appropriate value based on your business needs. Generally it is recommended that you keep the expiry time in the shared access signature to a small value so that the SAS is not misused as you're responsible paying for the data in your storage account and the outbound bandwidth.
I don't understand advantage of using SAS in my case as any user
having SAS can see image (for example my friend who receives image uri
with sas). So, is there any advantage? Can anyone explain me this?
Biggest advantage of SAS is that you can share resources in your storage account without sharing storage access keys. Furthermore you can restrict the access to these resources by specifying appropriate permissions and shared expiry. While it is true that anyone with SAS URL can access the resource (in case your user decides to share the SAS URL with someone else) and it is not a 100% fool-proof solution but there are ways to mitigate these. You could create short-lived SAS URLs and also restrict the usage of SAS URLs to certain IP addresses only (IP ACLing).
You may find this link helpful regarding some of the best practices around shared access signature: https://azure.microsoft.com/en-in/documentation/articles/storage-dotnet-shared-access-signature-part-1/#best-practices-for-using-shared-access-signatures.
Firstly, if you want to change the expiry time of an ad-hoc Shared Access Signature (SAS), you need to regenerate it (re-sign it) and redistribute this to all users of the SAS. This doesn't affect the validity of the existing SAS you're currently using.
If you want to revoke a SAS, you need to regenerate the Access Key for the Storage Account that signed the SAS in the first place (which also revokes all other SASs that it has signed). If you've used the Access Key elsewhere, you'll need to update those references as well.
A good practice is to use an Access Policy rather than ad-hoc SASs, as this provides a central point of control for the:
Start Time
End Time
Access permissions (Read, Write etc)
SASs linked to an Access Policy can be revoked by changing the expiry time to the past. Whilst you can delete the Access Policy to achieve the same effect, the old SAS will become valid again if you re-create the Access Policy with the same name.
It's not possible to set an indefinite expiry time for a SAS, and neither would it be good practice to - think of SASs as like shortcuts in file system to a file that bypass file permissions. A shortcut can't be revoked per-se or modified after you've created it - anyone anywhere in the world that obtains a copy would receive the same access.
For example, anyone with access to your application (or anyone with access to the network traffic, if you are using HTTP) could keep a copy of the SAS URL, and access any of the resources in that container - or distribute the URL and allow other unauthorised users to do so.
In your case, without SASs you would have served the images from a web server that required authentication (and maybe authorisation) before responding to requests. This introduces overhead, costs and potential complexity which SASs were partly designed to solve.
As you require authentication/authorisation for the application, I suggest you setup a service that generates SASs dynamically (programatically) with a reasonable expiry time, and refers your users to these URLs.
Reference: Using Shared Access Signatures (SAS)
Edit: Microsoft Azure Storage Explorer is really useful for managing Access Policies and generating SASs against them.
You can set a very long expiry time but this is not recommended by Microsoft and no security expert will ever recommend such thing as it defies the idea of SAS
https://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-shared-access-signature-part-1/
As for the second part of your question, I am not sure how do you allow them to upload the images, is it directly using SAS on the container level or they post to some code in your application and the application connect to Azure Storage and upload the files?
If you have a back end service, then you can eliminate SAS and make your service works as a proxy, only your service will read and write to Azure Storage using Storage Account Access Keys and the clients will access your service to read and write the images they need, in this case the clients will not have a direct access to Azure Storage.
Context:
We have a VSTS account https://blahblahblah.visualtudio.com
We have configured it to block outside access by using Azure Premium conditional access and specifying the public IPs of our work network. So interactive access is blocked from clients outside the internal network.
But this does not block Personal Access Tokens (PATs). Nor do I see a setting to disable or block use of PATs. PATs can allow access to most of the data in our VSTS account via the REST API. Without a mechanism like the Azure AD Premium conditional access (whitelist), anyone in the world could access or modify our data by merely stealing a PAT. This seems like a huge security hole to me. Am I missing a control for that vulnerability?
Ideally, we would have a whitelist in VSTS instead of having to rely on Azure AD Premium. then the VSTS service would block both interactive and API calls that did not originate in our designated safe locations. But that does not exist so far as I know.
So, how can we protect our data from users out in the world who might access our account data via the API path and a stolen PAT?
You can disable Basic Authentication and Alternate Credentials, but that will also disable a few features on VSTS (like SSH Git and Git access from some tools that don't support the OAuth workflow).
Personal Access Token cannot be disabled this way unfortunately. Though you could have people limit the scope to their tokens and have them only create limited time tokens.
It's likely that in the future the integration with AAD will be tighter and will be able to check AAD Conditional Access.
Another important note: Once the user has logged on using AAD, they can take their laptop/device with them to another location. As long as the AAD authentication is still valid, they will not be blocked access from the other location. Conditional Access is checked upon login and renewal of the token in the case of VSTS as far as I know.
Right now only due diligence on the side of your users can prevent unauthorized access to your account. Have them treat their PAT the same way as they treat other important secret information. Use short duration PAT's, limit their scope to only what is needed and store them securely, in a Password vault like Lastpass or Keepass.
PS: in a cloud world where machines regularly get new IP addresses assigned and where IPv6 will make it harder to single out groups of machines, pure IP restrictions are not the way to keep your data safe. IP is also one of the things that is relatively easily spoofed or hidden.
With the recent release of Azure AD, we would like to use Azure AD for our web application authentication, but we do not want to use SSO. We do not want users to be redirected to the Microsoft Account login screen, and then come back. We want to supply them with the login credential screen where we capture their username and password, and then we want to programatically do the authentication against Azure AD, and get back the claims identity.
The problem I have is that I cannot see how I can do that using the Graph API, and all the examples that look like it might work, only works on the previous [0.8] release. There is such a mix of examples that is supposed to work, but they don't simply because of the new release.
Can anyone tell me if this is even possible, and maybe point me in the direction of how to do it please.
I do not want to use ACS.
What you are asking for is not technically possible with Azure Active Directory today. That scenario could possibly be supported in the future, so check back from time to time.
We really encourage developers to rely on the in browser sign in experience. The reason is that because the browser allows the server to define the experience, it allows for much greater flexibility with respect to the kinds of credentials that can be employed. For instance, if you code your app to use only username and password, then it may need to be updated in order to take advantage of two factor authentication. If you rely on the browser based experience then your app can be totally agnostic to whether 2FA is being employed, or any other kind of authentication dance.
We recognize that there are some scenarios where this is not ideal or even practical and are looking at solutions to those scenarios that may be supported in the future.