I know that GetUserDefaultUILanguage API can retrieve the UI language identifier for the current user, but I need to call it from a service and find out the UI of a specific user by its user token. Is such possible?
A service runs under some account, so even if you could successfully call functions like this, they'd tell you about the account the service is running under, not the account of a user that might need the service to carry out operations on its behalf.
As such, you probably need to have the user program register itself (e.g., PID and UI language) with the service. The service can then store those and use them as needed.
To use functions like GetUserDefaultUILanguage() inside a service, it needs to be running as that user. Either set the service in the SCM to run under that specific user account, or else have its code impersonate the user dynamically when needed.
Related
I am using the camunda spring-boot-starter and running the embedded camunda engine.
For Authentication, we are using a JWT token and the user information exists in an outside database. From Camunda docs, what I understood is that, for Camunda Authorization like assigning A User Task to a user, will totally depend on the Camunda Database.
How should I use an outside user authenticated with an external system, for the Authorization purpose in the Camunda? Should I create a copy of the authenticated user in the Camunda Database?
As part of the authentication you can also tell Camunda which groups/roles the user belongs to. For instance as shown in this generic simple Spring Security example: https://github.com/camunda-consulting/code/tree/master/snippets/springboot-security-sso
specifically: https://github.com/camunda-consulting/code/blob/4a609b375c6564838e85a1bde7d70e5a9951ab64/snippets/springboot-security-sso/src/main/java/com/camunda/demo/filter/webapp/SpringSecurityAuthenticationProvider.java#L35
Another mechanism uses a custom identity provider (read-only or writable) as explained here: https://docs.camunda.org/manual/latest/user-guide/process-engine/identity-service/#custom-whitelist-for-user-group-and-tenant-ids
It is correct that the default implementation is the database identity service, which uses the engine database for managing users and groups.
However, this is only the case if no alternative identity service implementation is provided. Camunda also provides an LDAP identity service for an LDAP-based user/group repository and you can of course implement your own.
Once you have an authenticated user and user group information for the user, the detailed functional permissions are linked to these groups as shown here: https://docs.camunda.org/manual/latest/webapps/admin/authorization-management/
You don't have to manage users in Camunda and or to sync with another system. If user's authorizations (groups, roles) should be fetched from another system, then use the SPI mentioned above. Either way you don't need to create the users in the Camunda DB. When a request comes in you may set the user and its roles on the IdentityService. In your subsequent API usage the user id and the authorization will be considered (if auth is enabled). If authorizations are disabled, then you only need the user id, not the groups/roles. If you want to provide neither and handle everything in your custom code, then you can just complete task without the user's Id (but won't have the user info in the audit information).
I am creating a flask app to be used internally in my company. I would like to restrict what a user can do it based on its login ID. I read a lot about using LDAP3 but I don't think I can do what want which send the login ID to the server. There I would have a table which will register which part of the system has the permition to edit. If it try to change somenthing not permited the app will retrieve a warning message.
I won't to do that to avoid having to create a separate login functionality just for this app. I read that I should use AD authentication but I am not very familiarized with that and I would also like to avoid having to ask our IT department to create user groups there for each part of my system.
I know that I can do that using ASP .NET (at least I did once).
Any guidance will be apreciated.
I think you are looking for Role-based Authorization.
In order to use this functionality you will need to implement roles on your model file per the Data-models documentation.
This will allow you to assign users a role when they are created, and you can use a decorator on your routes to 'require' the user to have the role you want them to have before they access the endpoint.
I'm using Ember 2.3 with Ember Simple Auth 1.0 and am wondering if anyone had any suggestions on the best approach to handle the following situation:
With the particular industry my platform serves, most staff are actually independent contractors and therefore could belong to multiple businesses. With that said, I have some specific requirements that I'm trying to address:
Avoid having to create a separate account with separate credentials for each business the staff member belongs to.
Allow credentials to be revoked at any time for a particular account.
Allow for account-level permissions.
Make it simple to switch accounts from inside the application without having to fully-reauthenticate.
To achieve this, my initial implementation is based around issuing a single JWT (using ember-simple-auth-token) for each user account. The proposed authentication flow would be as follows:
User logs in with username and password
System authenticates and if credentials are valid, return a token for each account.
If the system returns no tokens, return an error.
If the system returns a single token, use that token by default and redirect to the authenticated area of the site.
If the system returns more than one token, display a list of the accounts associated with those tokens and allow the user to choose the one in which they will be assuming the role of at that point.
What to do when the system returns more than one token is where I have questions:
Is there a way to "intercept" to allow the user to choose which account/token to use before ESA commits the token to the session in local storage?
If I want the user to be able to switch accounts, is it just a matter of swapping out the token value in local storage?
If there's anything else I should consider, I'd appreciate the feedback. If you also happen to think this is a terrible approach and have some feedback, I'd absolutely love it.
Cheers.
From ESA's perspective the user would be authenticated when the backend responds with one or more tokens (you'll have to implement a custom authenticator and authorizer of course). The fact that the session actually contains multiple tokens for multiple accounts isn't relevant for ESA really - that would be sth. that you'd need to handle in your application code instead.
Once the session is authenticated with one or more tokens, you can access them via the session's data.authenticated property, e.g. this.get('session.data.authenticated.tokens') etc. You could store the currently active account the user wants to use in the session's non-authenticated area, e.g. this.get('session.data').set('activeToken', 'whatever').
Please help me soon.
I am writing a c++ code to run a service, it works fine on administrator account
but on Non-Admin user account, OpenSCManager() function return null.
Please tell me how to grant permission to non-admin user account to start and stop services.
Or do i need to do something else.
Please reply soon
Probably you're calling OpenSCManager specifying the SC_MANAGER_ALL_ACCESS flag, which actually requires a set of privileges that are given by default only to admins. To start/stop services here you just need to specify the SC_MANAGER_CONNECT flag, which is given by default to any authenticated user.
Now that you have a handle to the service manager, you have to use OpenService to get a handle to the service. To have rights to start/stop the service you should specify GENERIC_READ | GENERIC_EXECUTE as desired access (actually I think you can even narrow down the needed rights to just SERVICE_START and SERVICE_STOP and, if necessary, SERVICE_INTERROGATE).
Here is the problem: standard services DACL don't grant such rights to normal users, so you should change the DACL of the service you need to start to allow normal users to start/stop it; see here. For more info about access rights for services, see here.
If, instead of a single service, you want to allow a normal user to start/stop any service, I don't know if it is possible without changing all the DACLs, but in my opinion it's definitely a bad idea.
Note that even in the single service case, if the service is running under a privileged account (e.g. LocalSystem) or if it's a vital system service, letting unprivileged users mess with it it's still a bad idea. You should allow users to start/stop only services that aren't all that important for the system.
Out of curiosity, why do you need to let users start/stop services?
I am designing a Service to run under LocalSystem account on Win2000, XP and Vista. It will need access to users registry hives, sometimes for extended periods of time, both when the users are logged-in, and also, when they are not logged-in (IF the profile is local. If the profile is Roaming and not loaded, I will not attempt to load it.)
If the user is logged-on, I can get the Users access token by various means (E.g. from its Explorer process, or by receiving Logon events from the Service Control Manager) then use ImpersonateLoggedOnUser and RegOpenCurrentUser to access the User's hive. However, what are the implications if the User selects LogOff from the start menu while I am impersonating and have his hive open? Will the logoff be prevented? Will my impersonation be terminated?
If the user is not logged on, I can use RegLoadKey to directly open the hive NTUSER.DAT. (Impossible for a logged-on user). But what are the implications of this if the user decides to log-on (I suppose the hive will be locked and the logon either prevented, or may experience difficulty?)
I will be setting up some test projects to explore these ideas however, regardless of their apparent results, these questions are theoretical in terms of what type of problems might, or would, be caused by the user loggin in/out during these actions by the service.
Caveat: ImpersonateLoggedOnUser can ONLY be used either for a logged-on user (token obtained from process or SCM event) OR for a user for which I have the plaintext password to call WinLogon and obtain a token - TRUE / FALSE ? In other words although I have maximum permissions as LocalSystem and am able to change the user's password or even delete the user's account, if the user is not logged-on, it is totally impossible to create a new token to impersonate the user without having the the password?
Apparently, there is some risk of damaging a user's profile if it is already loaded by another process when the user logs in. In that case, the system will try to create a new subdirectory for the user.