In every IdentityServer4 Quick Start sample there are in-memory providers given for the resources, clients, and users. Are there any samples of the proper interface overrides needed for production?
For instance IProfileService is the class to be overridden for user management, however there are no examples that use this class and there is no specification in the reference section as to what the members of this class are. When implementing it you get the methods you need to override, but all the return types are Task and there is no helpful commentary on the specifics.
I had the same problem, and ended up looking at the default implementations (the way the IdentityServer4 implements these interfaces) here.
There's no IProfileManager so if you mean IProfileService here's how we're using it (to add claims to the access_token):
public Task GetProfileDataAsync(ProfileDataRequestContext context)
{
var claims = new List<Claim>();
context.IssuedClaims = claims;
return Task.FromResult(0);
}
You can now add your claims to that claims list and they will be added to the access_token which will be returned to the client.
Related
Much of the authorization and policy of the website I'm creating is wrapped up in group policy, not single user policy. There are some functions, such as searching for the existence of a user group in a user's profile, which need to be repeated over and over again. Since policies don't extend anything, would it be possible for a developer to create some sort of abstract policy object which included this function?
Policy classes do not need to extend base classes, you are free to extend whatever custom class you want. What matters is that the policy class provides the required policy check methods (which vary depending on the resource).
The only slight exception are policies for requests, they should (but currently do not have to) implement \Authorization\Policy\RequestPolicyInterface, however this doesn't stop you from extending classes or implementing additional interfaces.
When implementing IS4, we want to have a couple of extra fields on the /Account/Login form (we're building off of the Quickstart UI). The data provided by these fields (location info - 1) building and 2) station within the building) needs to be accessible when IProfileService is called as they are pieces of information used to determine the claims to be provided in GetProfileDataAsync(). We tried storing the data in HttpContext.Items, but that data is lost since there is a redirect that occurs before IProfileService is called.
Do you have any recommendations for how to pass this data back to IProfileService?
One of the extension methods on the HttpContext, SignInAsync, allows you to pass in any extra login related claims. If you add ‘building’ and ‘building_station’ as claims when you call SignInAsync from the AccountController, you should be able to access it through the HttpContext.
To do this you need to add the HttpContextAccessor to the IProfileService implementation through dependency injection, and once you get the HttpContext from it you should be be able to locate the appropriate claims in HttpContext.User.
I'm currently developing a back end and having my first run in with security laws etc. and it has complicated the design of my DB slightly:
Specification
Central server for app with DB containing limited user information (user_id, email, password (hashed and salted)) can be anywhere.
Organisations making use of our service require that all other information be stored in-house, so the database for that particular organisation is in their building.
The user IDs in our central database are used by multiple types of users in these organisations databases, where more info about that user is stored (phone number, name, address...)
Problem
With Spring Boot, I need to make it so the datasource used is determined by which user makes the request. I map users to their corresponding organisation's database within the central server so the information is there, but I'm not sure how to make this variable.
I understand there are methods involving adding another database config in the application.properties file. But as far as I'm aware this can't be changed (easily) once the server is deployed and running without a full redeploy, and I'm hoping to build this in such a way that adding another organisation only involves setting up their db, and adding another database details to the central server.
Extra detail
I'd like to use CrudRepository with hibernate entities for this. I plan on only generating user IDs on the central server.
Any pointers would be awesome.
Thanks!
The terminology for this is database multi-tenancy. There are multiple strategies for multi-tenancy: different databases, different schemas in the same database, and the same schema on one database with a defined discriminator.
You basically create a DataSourceBasedMultiTenantConnectionProviderImpl class which provides the connection to a datasource based on which tenant is requesting it, and a CurrentTenantIdentifierResolverImpl class which identifies who is the requesting tenant.
You can read more about it here. Since your tenants each have their own database, you would probably want to focus on the multi-tenancy separate database approach. It worked fine with CrudRepository when I implemented it. You also might want to find your own way of creating the tenant map, since I had 2 tenants and no need to add more at any point.
Heres a sample of the connection provider from when I implemented this:
public class DataSourceBasedMultiTenantConnectionProviderImpl extends AbstractDataSourceBasedMultiTenantConnectionProviderImpl {
private static final String DEFAULT_TENANT_ID = "A";
#Autowired
private DataSource datasourceA;
#Autowired
private DataSource datasourceB;
private Map<String, DataSource> map;
#PostConstruct
public void load() {
map = new HashMap<>();
map.put("A", datasourceA);
map.put("B", datasourceB);
}
#Override
protected DataSource selectAnyDataSource() {
return map.get(DEFAULT_TENANT_ID);
}
#Override
protected DataSource selectDataSource(String tenantIdentifier) {
return map.get(tenantIdentifier);
}
}
I'm updating code that interacts with the AD in our application. The current code uses the ActiveDs interface. I'm changing the code to use the System.DirectoryServices.AccountManagement namespace. Our application allows a user to store a password hint. This is stored in the AD under a user defined parameter. I know I can do this with the DirectoryEntry.Invoke("put") method.
Is there anyway to do this with UserPrincipal, or do I need to call the GetUnderlyingObject method and then the DirectoryEntry.Invoke("put") call?
Any suggestions/comments would be appreciated.
The UserPrincipal class is extensible, so you can "surface" more of the properties of the underlying DirectoryEntry object right on your user principal.
Using that extensibility technique, which is explained in the MSDN article Managing Directory Security Principals in the .NET Framework 3.5, you should be able to also make available a custom attribute (which I assume is how you store that password hint in your DirectoryEntry) on an extended UserPrincipal class.
This is more of a best practices question. Our org currently has "public read" permissions on our org wide defaults for custom objects. We cannot make this private because of the way its working now for internal employees or rather we are trying to avoid this.
I am also creating a customer portal with custom visual force pages...where I display data using SOQL queries.
Is it a good idea to add a clause on the SOQL query to return only those records where the account id matches the logged in user's acount id?
I did it and it works fine...But are there any pitfalls to this method that I am overlooking?
Thanks,
Calvin
Per the Visualforce Documentation
Because standard controllers execute in user mode, in which the
permissions, field-level security, and sharing rules of the current
user are enforced, extending a standard controller allows you to build
a Visualforce page that respects user permissions. Although the
extension class executes in system mode, the standard controller
executes in user mode. As with custom controllers, you can specify
whether a user can execute methods in a controller extension based on
the user's profile.
I believe the idea being, as long as your classes are public with sharing then permissions should be enforced and records should not be returned that the user cannot see (same with fields on a record).
per the Apex Documentation
Apex generally runs in system context; that is, the current user's
permissions, field-level security, and sharing rules aren’t taken into
account during code execution.
Use the with sharing keywords when declaring a class to enforce the sharing rules that apply to the current user. For example:
public with sharing class sharingClass {
// Code here
}
Use the without sharing keywords when declaring a class to ensure that the sharing rules for the current user are not enforced. For example:
public without sharing class noSharing {
// Code here
}
Otherwise you would have to spend hours ensuring that the right permissions applied at exactly the right time for the right user. It would almost completely defeat the purpose of a visualforce page!