I'm working on a background service which needs to ask several users' iTunes settings (the users will opt-in via a helper application which they run from their login). Is there an easy way to read the preferences for another user, than the current one, using CFPreferences ? The docs, for example for CFPreferencesCopyValue, explicitly state: 'Do not use arbitrary user and host names, instead pass the pre-defined domain qualifier constants.', when passing the 'userName' argument to the various functions.
The userName parameter in CFPreferencesCopyValue is somewhat misleading; the possible values are restricted to the following ones:
- kCFPreferencesAnyUser;
- kCFPreferencesCurrentUser;
It specifies the scope of the preferences you are accessing (either current user or all users). This also means that you cannot access preference of another user, even if you run as root.
Related
Is there any way to login other users account for admin user ?
Currently authentication based on Meteor Accounts
I saw this post but didn't working at all now.
The feature is important for us because when user have problem in system then admin need to see it this by simulating user account.
Thanks in advance.
It seems you want to impersonate a user. This means that you want to have Meteor.userId (or this.userId depending on context) reflect the _id of a specific user both on the client and the server.
afaict the only way to do this is to login as the user. Presumably you don't want to ask the user for their password so you have a couple of choices:
Save their existing password, replace it (temporarily) with a password of your choosing, then after you're done impersonating their account, restore their existing password.
You probably don't want to ask the user for their password and you don't need to. All you need to do is set aside Meteor.user.findOne(userId).services.password.bcrypt, then reset the password to your temporary value, then restore the original bcrypt value later.
The downside is that the original user would not be able to login while you are logged-in. Plus it's really hacky.
Extend Meteor's Accounts package to provide impersonation capability in a more elegant manner.
You might also look at validateLoginAttempt. The docs are unclear as to whether a failed login attempt could be overridden with a successful one but if it could then that would provide another pathway to solve your problem.
Instead of logging in as the users, which requires their password and which is a total no-no, you may use rather alanning:roles and allow the admin to assign the role of any user in order to draw views based the user's role.
This requires a well designed role system.
As a plus you could then at least load the documents associated with the user who you want to support.
This requires a well designed document and data model.
But generally spoken you should rather focus on writing good tests (test driven development) for components as unit tests, integration tests and UI tests.
This will reduce the need to manually view the app as an end user a lot.
The most common end user problems can be reduced by creating a good knowledge base like a wiki or video tutorials.
Even if then an error occurs in the end user side, I would rather try to implement a well designed error log that allows users automatically create tickets on error which also include the error stack.
All the above methods are to be favored before logging in AS THE USER.
As #Jankpunkt has already mentioned alanning-roles I can add something you can use without installing any external package.
Just keep a type key in the profile object of the users collection. Then define some types like 1 for super-admin, 2 for admin, 3 for general etc. Then check the authorisation of particular action by checking the value of user.profile.type key.
Caveats: Make sure you are checking the type in server side. By default profile field is writable from the client end, so if you are putting type field in the profile object make sure that you are not allowing users to modify users collection in the client end.
Here is how to restrict client end update in users collection:
Meteor.users.deny({
update() { return true; }
});
Read more on roles and permissions here:
https://guide.meteor.com/accounts.html#roles-and-permissions
Looking for the developer documentation as to how to modify a users application assignment. I would like to programatically assign, unassign and change the assignment details (ex: roles). So far I can't find that in the developer docs.
You can directly assign and remove users from applications via the Application User Operations.
Depending on what logic you're trying to implement, it might be better to:
Assign the users to groups. You can even setup rules to do this for you automatically based on conditions.
Add the group to the app
By using groups rather than assigning users to the app directly, you can automate more of the flow (i.e. users can be assigned to apps automatically based on user properties and conditions), as well as setup Sign-On, MFA, and password policies.
Our Web Application has a login screen: User can login with their Windows Accounts (the admin can use local accounts).
The Web Application uses the UserPrincipal in .NET-Framework to match the login name and password. The entered login will be split by the '\' into Domain part and SamAccountName part. E.g.:
Calamitas\Simon
But for local accounts in Windows it is possible to use the computer name instead the domain name:
ComputerName\LocalUser
And instead for the computer name it is possible to use a dot:
.\LocalUser
Where can I get a list of all these login patterns?
If you are calling FindByIdentity then the formats supported are listed in the IdentityType enum. This seems to be a subset of the types GetUserNameEx can return.
You have most of the important patterns covered already except for name#example.com, name#domain and example.com/name? It might also accept just a name but that lookup is going to be slow in a large domain forest.
There are also distinguished names (CN=Jeff Smith,OU=Sales,DC=Fabrikam,DC=COM) but they are hard to parse/validate.
Users are probably not going to use a GUID or a SID to log in.
If you are trying to validate form input then I would suggest allowing ?*\?* and ?*#?* (DOS syntax). Add S-?-?* to support SIDs.
I am front-ending an app with Shibboleth authentication. How can I retrieve the authenticated username in order to display it in my app?
You need to have that attribute released to you. Typically it will be added as a header to the request by the local SP, at least that's the way it works on IIS with the ISAPI extension.
You can access the Attributes in a manner specific to your application's language and environment. The preferred method is to use environment variables, but you can also use HTTP request headers, which can have some security issues because clients can "fake" whatever headers they want (however, some HTTP front-ends like nginx will drop headers that have underscores in them, which is what the Shibboleth Native SP would typically use).
If you're using Java on Tomcat, for example, you would have mod_proxy_ajp on Apache HTTP working with mod_shib2, and you would configure the SP to prepend "AJP_" to the header/variables so that the mod_proxy_ajp code puts those on the Request as Attributes instead of Headers.
Anyway, once you know that the username (possibly the Principal/Subject) is being passed to your application, you can simply access it via the typical Attribute access methods for your programming language as noted in the link above.
eduPerson Object Class Specification (200806)
2.2.8. eduPersonPrincipalName (defined in eduPerson 1.0); OID: 1.3.6.1.4.1.5923.1.1.1.6
RFC 4512 definition
( 1.3.6.1.4.1.5923.1.1.1.6
NAME 'eduPersonPrincipalName'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
Application utility class: standard; # of values: single
Definition
The "NetID" of the person for the purposes of inter-institutional authentication. It should be represented in the form "user#scope" where scope defines a local security domain. Multiple "#" signs are not recommended, but in any case, the first occurrence of the "#" sign starting from the left is to be taken as the delimiter between components. Thus, user identifier is to the left, security domain to the right of the first "#". This parsing rule conforms to the POSIX "greedy" disambiguation method in regular expression processing. When the scope is a registered domain name, the corresponding registrant organization is to be taken as the scope. For example, francis#trinity.edu would imply that the identity behind the ePPN has the "NetID" "francis" at the instituion of higher education that registered itself with the domain name "trinity.edu." If other value styles are used, their semantics will have to be profiled by the parties involved. Each value of scope defines a namespace within which the assigned principal names are unique. Given this rule, no pair of eduPersonPrincipalName values should clash. If they are the same, they refer to the same principal within the same administrative domain.
Notes
If populated, the user should be able to authenticate with this identifier, using locally operated services. Local authentication systems should be able to adequately affirm (to both local and remote applications) that the authenticated principal is the person to whom this identifier was issued.
The initial intent is to use this attribute within the Shibboleth project, http://shibboleth.internet2.edu/. However, it has quickly become clear that a number of other applications could also make good use of this attribute (e.g. H.323 video, chat software, etc). eduPersonPrincipalName (EPPN) would be used as follows: A resource owner, A, would look at B's directory entry to discover B's EPPN. A would then tell the local authorization system that B's EPPN is allowed to use the resource. When B tries to access the resource, the application (or access control infrastructure) would validate B's identity, check with the local authorization system to ensure that B has been granted the appropriate access privileges, and then either grant or deny access.
EPPN looks like a Kerberos identifier (principal#realm). A site might choose to locally implement EPPN as Kerberos principals. However, this is not a requirement. A site can choose to do authentication in any way that is locally acceptable.
Likewise, EPPN should NOT be confused with the user's published email address, although the two values may be the same. Some sites have chosen to make the user portion of email addresses and security principals the same character string; other sites have chosen not to do this. Even when they appear to be the same, they are used in different subsystems and for different purposes, and there is no requirement that they have to remain the same.
The uid attribute of the user's object within the local white pages directory may also contain a login id, a security principal; some systems (eg NDS) may put a login id in the cn attribute. These attributes are defined within objectclasses that are universal. Unfortunately, their use is not prescribed in a sufficiently precise and consistent manner for use with cross domain authorization. A variety of systems already make conflicting use of these attributes; consequently, we have defined this new attribute.
An assumption is that EPPNs are managed on an enterprise basis by the univ of univ.edu. A particular EPPN is assigned solely to the associated user; it is not a security principal identifier shared by more than one person. Lastly, each EPPN is unique within the local security domain.
How long, if ever, before a formerly assigned EPPN is reassigned to a differrent individual is an institutional decision. Some institutions will choose never to reassign EPPNs. Others may opt for a relatively short hiatus before reassignment. While this complicates the work of the relying parties, it is unavoidable given institutional autonomy. See MACE best practice documents on identifiers for further discussion of these issues.
This attribute should prove useful in creating some applications that are based on currently deployed technologies and on code that does not currently use LDAP or require a PKI. This attribute should help to create a framework to foster interesting inter-institutional collaborations between sites that use different technologies. In short, this attribute provides a foundation for yet another abstraction layer.
Example applications for which this attribute would be useful
controlling access to resources
Example (LDIF Fragment)
eduPersonPrincipalName: hputter#hsww.wiz
Syntax: directoryString; Indexing: pres,eq,sub
References:
http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonPrincipalName
I'm writing an application which needs to store login data for multiple (XMPP) accounts on Windows.
Currently the application stores them in Windows' "Stored User Names and Passwords" using CredRead and CredWrite. And here is the problem: The login name for an XMPP account cannot be changed (it's the account's JID), but Windows only stores user name/password pairs under a given target name. I use something like "xmpp:account#server.tld" for the target name and don't use the user name at all during login. The user can't even set the user name from within the application (it will be set to "account#server.tld" automatically instead).
Now I would like to prevent the user name to be changed to something different by the user (using control panel or rundll32.exe keymgr.dll, KRShowKeyMgr) or an other application as this is currently possible and somehow confusing because the actual value is ignored anyway. If I open up the "Stored User Names and Passwords" dialog (using rundll32.exe keymgr.dll, KRShowKeyMgr), the entries which are created by my application are listed as "xmpp:account#server.tld (LegacyGeneric)" and can be edited using the "Edit..." button.
The list contains also an entry for Windows Live (listed as "live_account#hotmail.com (WindowsLive)"), whose user name cannot be changed (trying so will bring up a message box saying: "Windows cannot save the logon information. Make sure the information is correct and that all required fields are completed.".
And here is (finally) my question: Can I get this behavior for my application as well? How can I change the credential type to something different than "LegcyGeneric"? Or is there a better way to store only the password for a given login name (maybe using Windows Data Protection), while still using some "standard" Windows way of storing them?
Any hints and answers are appreciated.