For my use case, I would like to add certain attributes(derived from roles) to all the JWTs. And this would be needed for multiple clients. Is there a way to define mappers for all the clients under a realm in a given Keycloak instance?
No, you can't define "global mappers".
Scope can be used for this "global" approach. Use some your default scope (scope which is executed implicitly), which is default for all your clients, (for example profile scope usually) and define your "global" mapper(s) there.
Related
In most apps there is the need to scope cached queries by default. Let's say you allow users to use multiple accounts. You'd probably want to scope each and every query to the account the user uses.
If queries are not scoped by default, we have to pass the accountId to every invocation of useQuery like so: useQuery([accountId, ...]).
I'd love to know if queryFn can be bound to a global key like this.
<QueryClientProvider client={queryClient} defaultKey={[accountId]}>{...children...}</QueryClientProvider>
So I'm sending all users through apache with mod_auth_kerb. All users come in with a default userRolesHeader of users.
I'd like to add extra roles for specific accounts, but I'm not seeing a good way to do that. If you could define the users in realm.properties and it would combine with the userRolesHeader, that would be useful.
Is there another way to do this? I don't see how it can be done with apache alone since REMOTE_USER isn't available during if/else logic processing.
#rundeck
rundeck.security.authorization.preauthenticated.userNameHeader=X-Forwarded-Uuid
rundeck.security.authorization.preauthenticated.userRolesHeader=X-Forwarded-Roles
#apache
RequestHeader set "X-Forwarded-Uuid" %{REMOTE_USER}s
RequestHeader set X-Forwarded-Roles users
Internally Rundeck gets only one method once, if you configure Rundeck to get the users from the realm.properties file, Rundeck seeks the roles from that file. Currently You can combine methods but the user/role in different methods doesn't.
Snowflake follows the role-based access control (RBAC) paradigm. Best practice for RBAC is, to have functional and access roles managing either user and clients or access privileges. This creates in worst-case a variety of roles that inherits permissions from and to each other. By nature, one can easily lose sight.
In snowflake, grants to roles and users are stored in ACCESS_USAGE.GRANTS_TO_ROLES and ACCESS_USAGE.GRANTS_TO_USERS. What is a proper approach to identify the data stewards/owner of a role automatically (if not labeled explicitly in a 3rd party tooling)?
Options I thought of:
recursive lookup of OWNERSHIP privileges of roles of roles (will generate a lot of false positives)
recursive discovery of a service account that has advanced permission to a role and lookup the service account owner
lookup over usage pattern of executed queries (might be actually more consumers than producers)
A couple of options:
Populate the role’s comment field with the relevant Data Steward information
Use Tags (in public preview)
I'm in charge of implementing a session state server with ASP.NET Core gRPC, and its corresponding client, to have session state management for a load-balanced group of ASP.NET Core applications. That means the client must implement IDistributedCache for that.
The methods Set and SetAsync have a parameter of type DistributedCacheEntryOptions and this class has the properties AbsoluteExpiration, AbsoluteExpirationRelativeToNow and SlidingExpiration. I presume these properties can be used to signal when a cache entry has expired, but how are they used and how am I to interpret them? Seeing that the 3 properties are nullables, is it that only one of the three is to be populated?
So, as far as I can tell, you're supposed to use only one of those properties (the one that matches your use case). In my case, all I had to do is to use SlidingExpiration and that covered my use case. Other contexts might require other strategies.
Can anybody explain why ForEach droplet has global scope, but not request scope?
I mean what this feature give us in performance (real-world app with many users) in comparison if it has the request scope.
If a component has request scope, it means that an instance (object) of this component will be created (time and memory resources) each time the component is requested. The more often requested - the more time is needed to create an objects. The more user\requests at a time - the more objects at a time. Global scope component are created once and can be re-used by all requests and different users.
ForEach droplet is stateless, can be used by many different requests\users at a time, so there is no reason to make it request scope.
Global scope means that the component is created only once. Droplets should be stateless because it's easier to use and maintain them. In your particular case, there's no point making ForEach droplet request scope because we can pass a new parameter to iterate through each time we call the droplet. On the other hand Form handlers should have request or session scope because they are intended to process users request, e.g. login process, submitting an order.