I have an ASP.NET Core app that I deploy in a containerized manner to Azure Kubernetes Service (AKS) and when running just a single replica of the app - it is functional and works as expected.
However, when I run multiple replicas - I run into am error - “Unable to protect the message.State” from the OIDC provider.
Upon further research I have figured out that using ASP.NET Core Data Protection as depicted here is the solution -
https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-5.0#persisting-keys-when-hosting-in-a-docker-container
However - the above link does not expand upon the usage pattern of it while storing the key in Azure Key Vault. Assuming I have protected my keys in AKV how do I actually get to use it in my app? Is there sample or guidance on this aspect?
First of all I would recommend that the same client instance (With AddOpenIDConnect(...) is the same that also handles the callback from your Identity Provider (/signin-oidc). The state parameter that it sets when it first redirects you to the identity provider must match the returned response (for security reasons).
To make sure that issued cookies in the users browser is valid all the time, you need to make sure:
All client instances uses the same data protection encryption key
The key is the same during redeployment.
You can for example store this key in Azure Key Vault, SQL-Server or somewhere else.
btw, I did a blog post about the Data Protection API here and how you could store the key-ring in AKV as well.
Related
I have an ASP.NET Core website that is used to store and retrieve encryption keys which are, at times, used to "sign transactions" on behalf of the user.
Since I'm in Azure, research indicates the most secure way to store these keys is via Azure Key Vault.
I've looked at this article, which shows that to gain access Azure Key Vault values, I would end up using credentials stored in the Web App's Application Configuration settings.
// Connect to Azure Key Vault using the Client Id and Client Secret (AAD) - Get them from Azure AD Application.
var keyVaultEndpoint = settings["AzureKeyVault:Endpoint"];
var keyVaultClientId = settings["AzureKeyVault:ClientId"];
var keyVaultClientSecret = settings["AzureKeyVault:ClientSecret"];
if (!string.IsNullOrEmpty(keyVaultEndpoint) && !string.IsNullOrEmpty(keyVaultClientId) && !string.IsNullOrEmpty(keyVaultClientSecret))
{
config.AddAzureKeyVault(keyVaultEndpoint, keyVaultClientId, keyVaultClientSecret, new DefaultKeyVaultSecretManager());
}
Web App Application Configuration settings are encrypted at rest and during transit, but their values can be leaked in a number of ways, hence the need for Key Vault.
My question, however, is if I have to store the Key Vault access credentials somewhere in the app configuration, doesn't that essentially limit the security of key vault values to the same level as what the configuration setting already provides? Does the extra level of indirection make a difference somehow?
What's the point of using Key Vault if someone can just access the Key Vault by reading the Key Vault credentials from the Web Config Settings?
What am I missing?
I have a Data Factory pipeline that calls a Logic App. The URL provided by the logic app designer includes a signature in the URL. In the Data Factory pipeline I have a Web activity that uses POST method to call the Logic App. This works, the app is called.
I would either prefer to separate this signature from the URL and store it in Azure Key Vault, or use authentication. Authentication options in Data Factory include; Basic, Managed Identity or Client Certificate. I tried to follow this article to enable authentication via Azure Active Directory OAuth but do not currently see how this would work with Azure Data Factory.
I know it is possible to enable API Management Gateway to enable more sophisticated authentication to APIs including Logic Apps but am not currently convinced that I should need to do this.
The other thing I noticed in the Logic App interface is that you cannot issue authorizations to execute. This differs from other Azure services like Data Lake for example where you can issue 'use-like' authorization to read a container. There is only the Authorization pane that can be used to define claims. I had a little go but I am missing key information.
Ultimately I would not want the signature exposed to developers including myself.
I believe you could pair the Managed Identity of the Web Activity with the Azure AD OAuth feature for Logic Apps.
The required claims need to be setup on the Authorization blade for validation of the tokens.
I personally like storing the PostURL in the Azure KeyVault then doing an Azure KeyVault GET API Call in ADF, then passing the output securely in ADF to the request to trigger the logic app. It's two activities which is like nothing and it's a secure method that can just use managed identity authentication that's Native in ADF.
Here is example of how you get a value from AKV:
Getting value from AKV
Here is the URL for Azure KeyVault example secret:
https://kv-ccok-ops-#{pipeline().globalParameters.Environment}.vault.azure.net//secrets/FILESERVER-UserName?api-version=7.1
Using value from AKV
This example should be super easy to follow.
I have checked many sample examples even by Microsoft on Azure ADB2C Authentication. All examples showing how to implement Azure ADB2C in Asp.Net Core Web App and Web Api together.
In Azure Portal, while registering Web App/Api, there is an option to generate App Key. My question is:
Do we really need to generate App Key and use it in Asp.Net Web App? I tried many samples and everything is fine but when I set invalid key in AzureAdB2COptions, its still working with no problem and not throwing any error. I removed the key from Azure Portal and its still working. Can anyone explain why?
The sample I used is here
Is this App Key for Web Api authentication?
As juunas mentioned, client secret is needed if your application exchanges a code for a token. It is used to prove Azure AD app's identity when requesting a token.
And implicit flow will not use a client secret to get the token.
Besides, if you use native/public client app, it would not be able to protect a secret. So generally we don't need client secret in native app.
I have tested the sample you shared. When I modify the ClientSecret in appsettings.json file and run this project, it will give an error requires me to correct the secret. You could have a quick test in an incognito window.
We are in the process of implementing Identity Server 4 with our .NET Core web app.
I went trough the Identity Server documentation. When configuring the Identity server (using DI) there is the line:
.AddTemporarySigningCredential
I'm trying to understand what this Signing credential is but couldn't figure out. Therefore I don't know if it's ok to use the built in temporary, or if I should provide a different one.
My question is, what is a signing credential and how should I use it?
In the Identity server documentation this is the definition:
Adds a signing key service that provides the specified key material to
the various token creation/validation services. You can pass in either
an X509Certificate2, a SigningCredential or a reference to a
certificate from the certificate store.
So it seems important :)
The Authorization Server will sign tokens with a key. Resource Server(s) should verify that the token's integrity with a key. Together they form a (usually asymmetric, e.g. public/private) key (pair). By default IdentityServer will publish the public key for verifying tokens via the /.well-known/openid-configuration endpoint.
For development scenarios, you typically want to skip the fuss of properly managing secrets like said keys (which is really important to do properly in production!). For these development scenarios you have the option of using adhoc solutions like AddTemporarySigningCredential, which was used for .NET Core 1.x.
With .NET Core 2.x this will change and you will need the AddDeveloperSigningCredential() extension method.
That answers the question of what it is. On how to use it: you simply call the method you need depending on your .NET Core version inside the ConfigureServices(...) method of your application's Startup class.
Apart from that you don't need to do anything special, except of course take care that you use a proper key pair in production.
See also the docs on Cryptography, Keys and HTTPS and the bit on Configuring Services for Keys. From the latter document, here's a relevant alternative for production cases:
AddSigningCredential
Adds a signing key service that provides the specified key material to the various token creation/validation services. You can pass in either an X509Certificate2, a SigningCredential or a reference to a certificate from the certificate store.
I'm evaluating WSO2 Identity Server and WSO2 API Manager.
I registered an API and an application on API Manager. I can call the resources successfully.
I could also add an user into Identity Server and log into that using oAuth authentication.
But, it's not too clear how I can use those two systems together. I would like to use API Manager to expose my API's to some applications. And, I would like to use Identity Server to log the final user. Is that possible? How can I "plug" those two systems?
I am not sure if that's the best way to do that, so, please, advice me.
Thanks
According to my understanding of your use case is you need to expose the API's securely. So you need to used WSO2 Identity Server and WSO2 API Manger. In addition to that you need the best approach for above use case.
With above two product we have below two option.
Configuring WSO2 Identity Server as the Key Manager in WSO2 API
Manager (This link gives a different version combination of both products)
Here we need to add key manger feature to the WSO2 IS.
Configuring the Pre-Packaged Identity Server 5.0.0 with API Manager
1.9.0
In here 1st option have manual configurations. But,2nd option minimized the manual configuration.
The purpose of using the Identity Server is not too clear. Is it to separate the authentication/authorization from the API Manager instance?
By default API Manager is shipped with a Key Management Server component that is responsible for all security and key related operations.This can be configured to authenticate users against a defined user store or multiple user stores. Authorization is based on oAuth 2.0. However, in a production deployment, we recommend that this component is deployed as a separate server instance so that it runs as an external Key Management Server.
This is done by simply using another copy of the API Manager distribution and configuring it as a Key Manager server node.
Hope this helps.
Regards,
Gillian
My understanding is,
if you wanted to use WSO2 API manager (AM) as an API gateway, you don't need a separate IS as AM included an IS engine with security mechanism included such as key manager.
If you need single sign on across all AM components, and you do NOT have other identity provider (IdP), you need a aeparate IS
However, if you do have a separate IdP, you don't need to install an IS server to implement SSO for AM, although the documentation from IS may suggest you do so. For example, a successful SSO implementation has been done with PingFederate/PingIdentity. See How to integrate WSO2 API Manager (AM) 1.10.0 with PingFederate SAML 2.0?