We're currently working on a project that's in Azure and I wanted to make use of the extension methods available to persist the data protection keys to Azure Blob Storage.
One of the methods provided accepts a URI with a sas token to establish the connection to the storage account. However, I'm curious as to how the connection could be re-established again once the SAS token expires. I have reviewed the source code and didn't see how that's possible.
It would be helpful if someone could shed some light on this.
https://github.com/aspnet/AspNetCore/blob/416d8cd1ea098eb643b4258247af3448f5545c32/src/DataProtection/AzureStorage/src/AzureDataProtectionBuilderExtensions.cs
Instead of hardcoding it, you can get SAS token in startup (Also keep in mind that it will slow down your App startup). But this also mean that to pick up new key your app needs restart.
You can have it as a config parameter and with each deploy write PowerShell script to load new SAS token
Generate long term key and encrypt with Keyvalt combined with Managed Service Identity (MSI), . (PS. I am not security expert so I am not sure if its 100% safe). So even someone obtain your key it will be encrypted.
Related
I want to make sure I understand how ImageFlow.NET server works with images stored on a private Azure Blob Storage container.
Currently, we access images directly from Azure Blob Storage and we need to create a SAS token for images to be available in our frontend apps -- inlcuding mobile apps.
Our primary interest in ImageFlow.NET server is resizing images on demand. Would we still need to generate a SAS token for each image if we use ImageFlow.NET server to handle images for us?
For example, if we were to request a downsized version of image myimage.jpg, which is stored on Azure Blob Storage, do we still need to generate a SAS token or will ImageFlow server simply pull the image and send it to the requesting app without a SAS token?
Imageflow.NET Server has an easy API if you need to change this or hook up a different blob storage provider or design.
In the default Azure plugin setup, Imageflow authenticates with Azure using the configured credentials to access protected blobs, but clients themselves do not need an SAS token. Imageflow's own access can be restricted via Azure and by configuring the allowed buckets list.
Often, you need to have authorization for client/browser access as well as for Imageflow getting to blob storage. You can use any of the existing ASP.NET systems and libraries for this as if you're protecting static files or pages, or you can use Imageflow's built-in signing system that is actually quite similar to SAS tokens.
You can configure Imageflow to require a signature be appended to URLs. There's a utility method for generating those.
Then it's on you to only give those URLs to users who are allowed to access them.
Essentially, Imageflow supports any client authentication/authorization system you want to add to the app.
If you need something customized between Imageflow and Azure, that's also easy to customize (In fact, there's a single file adapter in the example project that implements a different approach for cases where you don't want to limit which buckets Imageflow accesses).
I am building a ASP.NET Core application. The client has an old ASP.NET application that exposes an API for authentication. It asks for a username and a MD5 hashed password (don't ask me why it works this way). Unfortunately, I do not get back any type of authorization token in the response. All it returns is some info about the user and a success or failure flag. My app needs to authenticate any request. My app will be pretty small and will only have a few API endpoints. Basically it involves opening a form, filling it out, and then uploading it to a folder on the server. That's it.
I need to be able to create some type of session so that users don't have to keep typing their username and password over and over again. They may open several of these forms on the same day. I also need some way to reauthenticate with the legacy API on each request.
I know that the right solution here would be to create some type of SSO login system that both the legacy app and my app would use. But unfortunately we're working under a tight deadline and won't have time to implement and test it. We may work on it for Phase 2 of the project later on.
One option I thought about was caching the MD5 hashed password in the encrypted ASP.NET Core Identity cookie. That way, on each request, I can retrieve the cached password from the session cookie and reauthenticate with the legacy API. I've read many posts on here about how it's always a bad idea to store the password in a cookie even if it is encrypted.
Another option is to cache the password using ASP.NET Core Session State or something similar so that the password at least never leaves the server. The problem with this though is that if the app has to be restarted, I believe this cache would get deleted and cause the user to have to login again.
Another option I thought of: Maybe I don't need to reauthenticate with the legacy API every time and therefore don't need to cache any passwords in the first place? The client specified that my app should automatically log out the user if there is no activity for 10 minutes. So maybe my app only goes to the legacy API once at the beginning and after that maintains its own session separate from the legacy app? This doesn't seem like a good solution either though as it means a user could be authorized for my app while not being authorized for the legacy app (if their password changed or account got deleted for example).
Is there a solution I'm not thinking of here?
Going to answer my own question. I ended up talking to the client about this issue and they seem to not be too concerned about it even after letting them know the risks of caching a password using one of the above methods or a similar method. I let them know this is a bad practice and should use access tokens instead. After a certain point, if they don't care then there isn't much I can do. They did seem to be open to changing things later though but like I said, we're on a tight deadline for the 1st phase of this project.
For anyone else facing this issue, the important thing is to talk to the stakeholders of your app to make sure they understand what the risks are.
I'm trying to call an Azure API App configured with Azure AD authentication. Assume for the purposes of this question I cannot use the Azure SDK and need to write code to get a token and insert it into the API request.*
I have established that there are two modes - 'client flow' and 'server flow', where client flow entails following at least one redirect to an issuer to get a token, and server flow where the server does this for you. Since I'm talking about doing this in code, following redirects would be possible but fiddly, so I'd prefer to use a mode where the URI or URIs to visit are known ahead of time and return content, rather than redirecting. The following diagram illustrates how the gateway routes all requests.
I think the mode I need is client flow, which would go something like:
Get an access token from the identity provider (which is what? how do I find out where this resides? what is the format of the request I have to send to the IdP?)
Pass the access token to the gateway (in what format?)
Receive another token in the gateway response
Supply this token in a header when making an API request (which header?)
How am I supposed to do this? The Azure documentation doesn't give enough detail about how it works, and expects all users to just use the SDK, which hides what is actually happening.
The actual reason is that ultimately this will need to be called from BizTalk, which uses the WCF WebHttpBinding to call restful services. I'm writing a custom behaviour to insert a token header into the request, but I need to know how this token should be acquired. It's possible to run arbitrary code in BizTalk but trying to do this makes the solution complicated, and config-only or mostly-config with minimal, loosely-coupled code is the simpler solution
Just want to understand your scenario better, Because you are going to use it from BizTalk Receive Pipeline, The scenario can be simplified by enabling a customer authentication token right ? Basic username and password for your API you have hosted on the cloud. Does BizTalk want to authenticate it self with tokens for each AD User ?
To answer some of your questions
Get an access token from the identity provider (which is what? how do I find out where this resides? what is the format of the request I have to send to the IdP?)
After you have configured your AD configuration, Once you have completed the authentication, I am assuming your are using ASP.Net here, You can find everything you need about the claims on your Thread.CurrentPrincipal, You can convert it to ClaimsPrincipal like so var claimsPrincipal = Thread.CurrentPrincipal as ClaimsPrincipal; and then you will find a lot of good information on this object. Name of the user logged in, list of claims the principal has etc. I have not explored every avenue here, but this should be a good starting point.
Your API App is running on this process which means you have access to these claims in your API App code as well.
I would build a custom pipeline in BizTalk that uses Azure SDK to authenciate and build this scenario, it is a bit complicated but it will give you more control over what goes through the pipeline as well when authentication fails with permission issues and so on.
What is the reference architecture for adding authentication and authorization to a mobile application. Do I need access tokens infrastructure or can I just use validation of a token data using private-public key pair. Do I need a dedicated Identity server(like wso2 identity server) incase I also want to release a developer API.
Thanks in advnace
Update
Things I have tried: I have worked on a project which uses the PKI based validation for every request(token data encrypted at client, token and encrypted data sent over to the server with every request and server decrypts to validate the client) this is a custom implementation, this I feel not the best way to do this, done some basic research to find the right way to do it. Found OpenAM and WSO2 IS, which can connect against multiple user store. They support token based authentication and policy based access control among other features.
What I'am looking for here: Am I on the right track, shall I goahead evaluating the two products, given that I also want to use the same platform another part of the same application which is web-based.
I'd like to create an open source project using the GitHub API, but I came across a problem having my secret key in the source code. I've read from various places to never include any secret keys in the source and I agree with that. I've also found a couple vague references about authenticating through a web sever instead of making users acquire their own API keys.
From my understanding it would go something like this:
When it comes time to authenticate with GitHub, I would have the user send a request to my server. From there, I would authenticate with GitHub using my own API keys and after a successful authentication, return the signature to the user who made the request. From that point on they could communicate directly with GitHub. Is that correct?
If that is how it works, I would love to know a little more about the process. It's my first time working with APIs so I'm pretty new to this.
I never received an answer to this question so I thought I would pass along what I found in the mean time.
The main concern with open sourcing a project that utilizes an API is disclosing your client secret (at least in the case of GitHub, which is why I posted this question). You should never include your client secret in the source. If someone has your client secret and client id they can effectively impersonate your application.
So, that leaves two options.
1). Run your own simple server.
2). Require everyone who forks your project to get their own GitHub API keys.
I would suggest going with option 2. If you open source an application, it's no longer yours, and you don't have a say in what other people will do with it. So, why would you want to be accountable for what someone else's application does while using your client id and secret?
There is also another problem here. Once you authenticate with GitHub and get an Auth Token, you need to somehow securely store that Auth Token. I didn't realize it initially, but it's basically a password. If you store the Auth Token in plain text and someone else recovers it, they can make a request to the API and retrieve all of the users data. (This is using OAuth2 and bearer tokens.)
There's really not a good way to store the auth token on the client. Which also presents another problem when you are trying to open source your project. Whoever uses your open source project will essentially need to use their own server for the initial authentication and then also to store the auth token.
Just some things to keep in mind.