I'm attempting to develop a .NET Core Identity Server but I can't seem to figure out where to hook in to persist consents in a database. My understanding is that when the use consents to the scopes of an application and checks the Remember Consent checkbox that in only stored in memory by default and if the Identity Server were to restart, the user would have to consent again. Is there a way to persist consent in something like a database so it can be remembered beyond a service restart?
you can use something like Entity framework to persist data in the database,
here is the docs for how to configure EF with Identity Server.
Related
Can someone help me understand the difference between the Service Principal created when I create an App Registration in AAD and the Managed Identity that gets created when I enable "System Assigned" on the Identity blade of an App Service?
We have an App Service that we are developing that we have created an App Registration for and we have also enabled the System Assigned identity. When we go into Enterprise Applications under AAD and search for our app, it comes up with 2 entries. One for the Managed Identity and one for the Service Principal created as part of the App Registration. We are trying to understand which one we would use to give the app permissions to write to an Azure SQL DB.
Managed Identities are essentially service principals wrapped with Microsoft logic to make accessing resources simpler. Although, sometimes adding more layers may complicate things, the idea is to make it easier, simpler, and less consumer interactive.
For your scenario, you'll want to think about what you would like to do. Would you like to have more control and implement your own logic with an Azure SQL DB protected by AAD, or try utilizing Microsoft's Managed Identity to protect/access the Azure SQL DB resource. (Ideally the Managed Identity path should be less work)
The tutorial for using Managed Identities to access an azure SQL db from an app service can be found here :
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi
The docs for protecting an Azure SQL DB using Azure AD can be found here :
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-aad-authentication
Furthermore Managed Identities are explained in the official Microsoft documentation here :
https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
It's important to note that there are two kinds of Managed Identities.
From the documentation:
A system-assigned managed identity is enabled directly on an Azure
service instance. When the identity is enabled, Azure creates an
identity for the instance in the Azure AD tenant that's trusted by the
subscription of the instance. After the identity is created, the
credentials are provisioned onto the instance. The lifecycle of a
system-assigned identity is directly tied to the Azure service
instance that it's enabled on. If the instance is deleted, Azure
automatically cleans up the credentials and the identity in Azure AD.
A user-assigned managed identity is created as a standalone Azure
resource. Through a create process, Azure creates an identity in the
Azure AD tenant that's trusted by the subscription in use. After the
identity is created, the identity can be assigned to one or more Azure
service instances. The lifecycle of a user-assigned identity is
managed separately from the lifecycle of the Azure service instances
to which it's assigned.
The picture from the official docs also gives a good example of a VM using MSI(Managed Service Identity).
This is Provided below:
In addition to that, the App Service Managed Identity documentation can be found here :
https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity
I would like to elaborate a little further as the topic around service principals and app registrations in Azure can be confusing.
As you noticed, a service principal will get created in your AAD tenant when you turn on system-assigned managed identity for a resource in Azure. This service principal is tied to the lifecycle of your resource or in other words: If you delete your App Service, Azure will delete the service principal for you [2].
Beside service principals, there are other object types that live inside a tenant: User principals and application objects. As the name suggests, user principals identify a user while a service principal can be used to either identify a resource in Azure or an application object. To both types of principals you can assign roles, as you mentioned you can create a new user in your database and use the system-assigned identity (Service Principal 1 in the image below) to let Azure SQL know that your App Service has permissions to access the database [3]. This is marked in red in the image.
When you create an app registration, two objects are created: An application object and a service principal in your tenant (this is "Service Principal 2") [4]. You could now use this service principal as well to give it permissions to access the database (marked in orange in the image) but this service principal is not tied to your Azure App Service and doesn't represent it. In other words, if you want to use Service Principal 2 in your App Service, beside creating a user for this service principal in your database you'd additionally also need to get an access token for this service principal whenever you create a new SQL connection to the database in your application. It's possible but a bit more inconvenient and the beauty of using system-assigned identities is that your App Service knows about its service principal already and you don't have to manage it on your own (e.g., delete it when your App Service gets deleted).
Long story short: Use the system-assigned managed identity in your use case.
[2] https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview#managed-identity-types
[3] https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi#grant-permissions-to-managed-identity
[4] https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
You can only use the managed identity that you have enabled in your App Service for authentication to AAD which eventually allows you to access your Azure SQL instance based on roles/permissions. I'd tried using the service principal/Enterprise Application created as part of App Registration process for authentication and it didn't work.
The way I see it is that the App Service is what runs/hosts your application and only this managed identity/SP is available to your running application for authentication to AAD.
The Service principal/Enterprise Application is being used internally for some other purpose and, it is not available to our application for authentication to AAD.
Just a wee note. App Registration may live without Service Principal. App Registration may represent an application that is consumed, not necessarily the consumer.
Managed Identity is solely a client-based identity.
E.g. Your App Service is acting as a client, when accessing Azure SQL. In this case you don't need an app registration and its service principal at all. You will only need a Managed Identity (which is a Service Principal).
When your App Service (A) is opposed to access another App Service (B) then again your App Service (A) does not need an app registration. But App Service B needs to have an app registration.
Imo when you want to use the credential-less approach in Azure, an app registration is acting as the server part and a Managed Identity (system - or user-assigned) is considered to be the client part.
Good afternoon,
I am writing a front-end for a research database that holds sensitive health information. My institution has a policy that user actions be logged by the SQL server so that they can perform audits on the server log files in the event of a breach.
Because of this policy, I cannot connect Django to the db as a system user (otherwise, all users of the front-end actions would be logged by the server as the Django system user instead as the actual user individually).
Is there a way to connect to the DB using per user credentials so that actions performed on the front end will be logged as that user on the db server? I have been able to find a lot of information about using multiple databases, but nothing about per user authentication of those databases.
Thank you in advanced!
I don't think you can do that, the user that connect to the database need to have access to all the tables.
I had a similar issue when I wanted to use Django models outside Django and restrict access to certain models for certain users.
I ended up using SQLAlchemy and its automap feature on the existing Django database. Then you can connect to the database using your SQL users.
However, if you don't mind all the users accessing all the tables and are only concerned about the logs, maybe you can use a different settings.py or at least a different DATABASES configuration for each user?
I was able to accomplish this by giving the SQL user the IMPERSONATE permission and performing EXECUTE AS prior to the DB queries that I needed to have logged in models.py.
cursor = self.connection.cursor()
try:
cursor.execute("EXECUTE AS " + get_current_user()
except DatabaseError as e:
cursor.close()
raise e
We have a requirement that user account can provide username/password for database. This means that after user account is loaded, the user should use his own database connection for persistence.
How do I configure that in Spring Data?
Which database?
Which ORM implementation?
Spring has the AbstractRoutingDataSource, which lets you change the DataSource at runtime.
You could also use a delegation pattern, where the web server connects as a limited user, and then changes role to a different user if their authentication is successful. See How to run SQL SET statements against db at start of connection/session using Hibernate? and Switch role after connecting to database
You'll probably need to disable caching in your ORM too.
I have a MS SQL Server with a DB that is constantly updated.
I have the credentials to access it with admin privileges.
And I'm making a Java EE webapp to display (hence, only display) its data.
But I have to make sure that, under any consequences,
My webapp doesn't modify the DB.
And no, the owners of the DB don't want to make an unprivileged user for the webapp.
Any ideas? I'm using JDBC + JPA.
In EclipseLink you could mark all your objects as #ReadOnly, so they won't be written.
You could also register an event listener to throw an error on persist, update or remove.
I've read how IBM's WebSphere can propagate the identity of a user back to a backend database (http://www.ibm.com/developerworks/websphere/techjournal/0506_barghouthi/0506_barghouthi.html). Does JBoss have similar functionality? Ideally, I'd like to be able to login to my JBoss application using SPNEGO and propagate that identity back to a PostgreSQL database using Kerberos or some other mechanism. Is this possible?
The article you've linked to could be used for that, but there are some caveats.
Having the app server re-authenticate as different users using Kerberos is probably not realistic. From my knowledge of Kerberos (admittedly limited), it is designed so that end-user interaction is required to do an actual authentication handshake. The user does the handshake with the app server over HTTP-- there isn't really a mechanism for asking them to re-authenticate with the DB itself.
You could use their hooks to issue "SET SESSION AUTHORIZATION TO ..." commands to PostgreSQL, though, if your app server performs its connections to the DB as a superuser. That doesn't actually re-authenticate, just changes the session authorisation role temporarily.
You could also use one of the myriad "store some session information in the DB" solutions (custom variables, PL/Perl etc global variables) and use their hooks to work with that. This is actually what their Oracle solution seems to do, it sets the client identifier which iirc is just a global variable in dbms_util somewhere that is included in views showing current sessions (and postgresql 9.0 has an "application name" that performs the same role)