10709 Posts in 2390 Topics by 1763 members
|Go to End|
Security Vulnerability & Inconvenience Issue with External Authentication/Auth_External's AutoAdd Feature
20 February 2009 at 6:30am Last edited: 20 February 2009 6:32am
In the process of writing an External Authentication/auth_external driver, I have encountered an issue that both inconveniences the user and presents a security vulnerability if auth_externalâ€™s AutoAdd feature is enabled.
Problem: If a SilverStripe userâ€™ username is changed in the external credential store and then that user logs into SS, a new SS account will be created. The account associated with their old username will be orphaned.
Example: Person has a username of â€œtomâ€ in the external credentials store and (thus) a SS account named â€œtomâ€. Username is changed to â€œtsmithâ€ in external credentials store. The first time â€œtsmithâ€ is used to log in to SS, a new SS account named â€œtsmithâ€ is created. Account â€œtomâ€ is orphaned. The member no longer has access to any data or rights associated with their old username.
In addition to inconveniencing the user (loosing rights, etc.) , this poses a security issue. Suppose that a different member is assigned the username â€œtomâ€ in the external credentials store. When that â€œtomâ€ logs into SS, he will have access to the rights and data associated with the previous â€œtomâ€.
Possible Solution: Allow auth_external drivers the option to return a user handle which will be used to locate the appropriate account in SS (instead of using the username for this look up). Ideally, this user handle would be a permanent, unique user identifier (example: Active Directoryâ€™s SID).
Example: After successfully verifying credentials, auth_external driver returns an array with these elements: firstname, surname, email and id. SSâ€™s user list is queried for a user with a â€œMember.External_UserID = idâ€ and a Member.External_SourceID equal to the current authentication source.
If an id element is not included in the array returned by the auth_external driver, or if the driver returns true instead of an array, auth_external would use the username (as it does at present) to locate the appropriate SS account. Thus, existing auth_external drivers will still work without requiring modification.
Iâ€™d be interested in assisting with making this modification. How would I go about making sure that Iâ€™m doing things in the correct way/checking if the solution has a good possibility in making it into the code base/etc.?
Re: Security Vulnerability & Inconvenience Issue with External Authentication/Auth_External's AutoAdd Feature
20 March 2009 at 3:13am
Documented in ticket #3742.
|Go to Top|