Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

All other Modules /

Discuss all other Modules here.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Security Vulnerability & Inconvenience Issue with External Authentication/Auth_External's AutoAdd Feature


Go to End


2 Posts   1543 Views

Avatar
Ben Gribaudo

Community Member, 181 Posts

20 February 2009 at 6:30am

Edited: 20/02/2009 6:32am

Hello,
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.?

Thank you,
Ben

Avatar
Ben Gribaudo

Community Member, 181 Posts

20 March 2009 at 3:13am

Documented in ticket #3742.