I am developing a .Net Core app that is required to access an Azure SQL database. We want to encrypt some of the fields and have set up a secure enclave. We originally used deterministic encryption and found out we need a little more functionality - like using joins and 'like'. So we're switching to randomized encryption for some of the fields. Now I'm getting an error in my app when reading the data from the database:
Attestation URL has not been specified in the connection string
Is an Attestation Provider necessary? or am I missing some kind of configuration?
Related
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.
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.
Worklight 6.1 documentation identifies that "credentials" such as password can be added to the user identity object (UIO) provided to WL.Server.setActiveUser().
How & where is the UIO stored on the WL server, and is this considered a secure storage?
Trying to understand the security implications of storing password in this structure to be retrieved and used for subsequent back-end access (Cloud) requests. If not secure, can encryption be applied to the any part of the UIO?
Appreciate any advice you can provide.
The User Identity object is kept in memory and is scoped to the current session.
In other words, the credentials are not persisted; one would need to dump the server memory and dig through it or connect with a debugger. It's considered secure. The production server is also supposed to run in a secure environment with limited access to the process, etc... of course.
The credentials stored in this object can be used by the adapter to authenticate with a back-end on behalf of the user.
In a HTTP adapter, the authentication schemes Basic, Digest and NTLM use that technique
In non-HTTP adapter and in custom authentication schemes, the developer can use those credentials as necessary.
I have been killing myself over this for a couple weeks now and cannot find a viable solution. Here's my scenario:
I have a DTSX package that imports user data from an external database. It then creates user accounts and profiles in the local database. Users can also be created via a custom ASP.NET Membership Provider. The provider must be able to authenticate both types of users.
This was all fine and dandy during development because passwords were stored as clear text. However, now that we're ready for release the passwords format of the provider must be set to encrypted and so the users created via the DTSX must be created with an encrypted password. (I'd prefer the passwords were hashed but the client's requirements are that passwords be recoverable). The real problem seems to be creating an encrypted password within the DTSX that will be decryptable by the ASP.NET Membership Provider.
My original solution was to have the DTSX call a CLR stored procedure that had access to the same encryption logic as the provider. I got it working but our client wouldn't enable CLR integration. So that's out the window. Now I'm investigating alternatives. One alternative is to simply use the built-in encryption methods of T-SQL. But how do I share the keys used for the encryption/decryption?
My question is, is it possible to generate a password in T-SQL, say using EncryptByKey, that will also be decryptable by my provider? This means that the key in SQL must match the key in my machineKey configuration. I have no idea if this is possible.
Any insight/help is tremendously appreciated.
why don't you use a script task inside your dtsx to encrypt the user password?
I'm trying to understand how windows authentication / encryption works with the NetTcpBinding in WCF. I need to know exactly what encryption algorithm is used to encrypt the data going across the wire (and some documentation to prove it). Will windows authentication / encryption still work if the client and or host is not on a domain?
The netTcpBinding using Windows Credentials requires the caller and the service to be on the same domain - or at least on mutually trusting domains. Otherwise, the server won't be able to verify the Windows credentials and will refuse the service call.
As for encryption : you can even pick and choose which one you'd like ! :-) TripleDES, AES - you name it, with varying key lengths, too.
See the Fundamentals of WCF Security article - it talks about all aspects of security and encryption; also see the MSDN Docs on Securing Services which goes into some more detail; a good overview can be found here showing the properties of the basicHttp transport security element.
Last year I had to implement a distributed system using wcf that required a mechanism both safe and performant across all layers of the system. We decided for creating our own security architecture by creating a binary encrypted token. The encrypted token contained all permissions a given user had.
So for example a user would log in into the system and if successfully authenticated it would receive an encrypted token back. This token was stored locally on the web client. All further requests by the user would contain that token. The token was used in several levels of the architecture. The web server would use it to decide what visual elements to enable or disable. Since the service layer was exposed to the internet, each open door would check the token for authentication and check if that token had the proper permission to execute a given task. The business layer could check again for a more specific right included in the token.
The advantages:
It didn't matter if we were using NetTcpBinding or any other type of binding (and we did use more than one type of binding).
We saved a lot of round trips to the database
We could use the same token on different platforms
I know it probably doesn't answer your specific questions, but it will maybe give you some for food for thought while you're still deciding on the intra-layer architecture of your system.