I am currently working on a few services that uses keyvault, authenticating with ClientCertificateCredential / Registered Apps. These are running on-premise.
Looking into using Azure App Configuration in a similar way, combined with keyvault. So a couple of questions arises:
Can i authorize against App Configuration the same way as with KeyVault, using ClientCertificateCredential ? If yes, how ?
If not, another option is to use a connection string against App Config. However, this is a secret, and should be stored in keyvault (absolutely not in appsettings.json). That means I have to access keyvault before setting up App Config. Is there a clean way to do this ?
Or, perhaps there is something else I should consider.
• Yes, you can surely authorize against App configuration as you do against key vault to retrieve client secrets, connection strings and other sensitive information with the help of managed identities. Managed identities create a service principal for the said application when enabled depending on the user to be assigned to that application or directly to the application itself as a system assigned managed identity that is created for the lifetime of that application.
By leveraging managed identity, it eliminates the need for an access token that contains secrets. Your code can access the App Configuration store using only the service endpoint. You can embed this URL in your code directly without exposing any secret.
• For more information on configuring managed identity to access the application configuration without exposing or leveraging any type of access token, please refer to the documentation link below for more details: -
https://learn.microsoft.com/en-us/azure/azure-app-configuration/howto-integrate-azure-managed-service-identity?tabs=core5x
Related
Been struggling with this for a day, and am finally reaching out for help. I'm attempting to use Azure Key Vault to store some configs in a Typescript application. I've created a service principle in Azure Active Directory and a Key Vault. In the Key Vault, I've gone to Role Assignments and given the app the role Key Vault Secrets User (which should provide list and read permissions). From what I can tell, my app is successfully authenticating, but when it requests a secret, it is getting a 403. What step could I be missing?
Log which suggests the authentication was successful
azure:identity:info IdentityClient: [https://login.microsoftonline.com/38e3589f-a40f-4fe6-beee-f4028442450e/oauth2/v2.0/token] token acquired, expires on 1593536920022
Log with the failure
The user, group or application 'appid=355ca45f-a94f-43e6-9234-65c713965c9b;oid=524f25bb-ee3f-4216-8474-1f01fd79f1f8;iss=https://sts.windows.net/38e3589f-a40f-4fe6-beee-f4028442450e/' does not have secrets get permission on key vault '<MyVault>;location=westus2'. For help resolving this issue, please see https://go.microsoft.com/fwlink/?linkid=2125287
The step I missed was adding an Access Policy. I don't understand the difference between Access control (IAM) and Access Policies, so I don't understand why both are required. Hope this helps someone else.
I don't understand the difference between Access control (IAM) and Access Policies, so I don't understand why both are required.
Actually, to access the secret in the keyvault, the permission in Access Policies is enough.
The access of the keyvault is divided into two parts, management plane(Access control (IAM)) and data plane(Access Policies).
The permissions in management plane let you manage the keyvault, e.g. set Key Vault tags, the permissions in data plane let you do operations on the secret, key, certificate.
In your case, even if you give the app(service principal) an RBAC role in the Access control (IAM), it will not have the permission to access the secret, so you need to add it to the access policies.
Something you should note is some roles have the permission to add access policies, e.g. Contributor, it means if you give the role to your app, it will be able to add itself to the access policies. But if it does not add itself to the access policies, it will not have the data plane permission.
For more details, you could refer to this doc - Secure access to a key vault.
When we are trying to retrieve secret from keyvault using KeyVaultClient (c#) we are getting 403 access denied even though the same user can access the vault secret from Azure Portal. If we give explicit access to the user on key vault then we are able to retrieve the secrets. This looks like an issue and please help on possible workarounds.
You may not have a service principal created for your application yet. If so, create that first and then use the object ID of the service principal to authorize access for the application. If you are using a VM you also need to add the VM service principal to the Keyvault's policies.
Take a look at this sample code to see how to create application and service principal and give permission to the service principal.
This was due to while generating token Group claims were not getting set and hence key vault was checking only of direct permissions. Once we enable group claims by following these steps from here then it is working fine now ..
I'm working on my master where I have to design and prove a solution to expose some university legacy services. None of them have controlled access, so other feature needed is this security layer.
To make this possible I'm using wso2 products: wso2ebs to make some orchestration and messaging transformation; wso2is to connect to a shibboleth idp that already exists; and wso2am to put everything together and expose the services.
I already have the identity provider (Shibboleth) configured on wso2is. I use this http://xacmlinfo.org/2014/12/10/federation-testshib/ to prove it.
To make the authentication layer, I'm not sure but I think that I can use this http://wso2.com/library/articles/2015/03/bring-your-social-identity-to-perform-organizational-authorization-actions-with-wso2-identity-server/ to make the bond between wso2is and wso2am.
But there is a use case I can't solve: wso2am give me an oauth like environment to expose my private services, but how can a student (end user) manage is authorisations? I as a student which use a mobile app that consume information given by an api exposed by wso2am, want to revoke this this authorisations given previously to this mobile app. How can I do this?
TLDR:
If wso2am use an oauth like environment to expose apis, is there a way to the end user revoke an authorisation given previously to an mobile app that make use of an api exposed by wso2apim?
There are two options
If you have client_id, Secret and access token on your hand you can use https://docs.wso2.com/display/AM190/Token+API revoking access tokens part
If not you can use revokeAuthzForAppsByResoureOwner operation in OAuthAdminService
Upgrading some legacy code using the old SDK, I would access dynamoDB using an AWS_KEY and Secret_KEY packaged in credentials that were then given to an AWSDynamoDbClient object. In version 2.0 of the SDK this client object is no longer available in AWSDynamoDB.h. All the documentation now points to Cognito for authentication so is the old way of access deprecated and the Keys not used anymore?
When you use Amazon Cognito, the service takes care of all the steps necessary to create a unique identifier for your app’s users and retrieve temporary, limited privilege AWS credentials. This means that you can follow security best practices, and use these temporary, limited privilege credentials instead of having to hardcode credentials into your app.
You can still use AccessKey and SecretKey with AWSStaticCredentialsProvider, but we discourage its use in production apps for security concerns.
I am building a chrome extension which will interact with salesforce-chatter api. But for a user using oAuth(User agent flow) authentication, I need to embed my client key in my extension.
Will this cause any security problem? Or is there a way to use oAuth without embedding client id in my extension?
The client id has to be included into a request, so the provider knows that the request came from you, as #Matt Lacey already pointed out. Normally, the provider also issues a confidential client secret that is additionally included into the access token request, so the provider can verify that your app is allowed to use that client id.
Chrome extensions run on an open platform and the platform itself provides no methods for either authenticating the extension against a server (which salesforce would then also have to support) or storing properties securely (would be hard, if not impossible on an open platform), so keeping the client secret confidential is unfortunately not possible.
As this is a common problem, it is already considered in the OAuth specification (see section 10.1 Client Authentication and 10.2 Client Impersonation). The provider is therefore required to do additional checks, but on the client side you can't do anything to effectively improve security.
If you want some more insight into how this will be handled on Android devices in the future, check out my answer here.
You have to embed the client ID in the extension to let Salesforce know what the app is that's trying to authenticate. These client IDs are intended to always be stored and passed to the server, so as long as you're storing it in a secure manner there shouldn't be a problem.
As Matt explained if you are creating a packaged app you will be forced to include the client id. Another solutions is to write the app as a hosted app:
What is the difference between packaged apps and hosted apps?
The drawback of this is the added complexity of managing a web server. But it will allow greater security.