I have a club membership site that I created that provides member only access to online copies of the club magazine, forum, gallery etc which is also used to maintain the actual membership list for the club including allowing members of branch committees to print out reports of the members belonging to their branch.
One of the branches has just created their own members only area on their site and has contacted me about the possibility of providing a way for members of the other branches to have access to their members only area. The problem being that they do not have and will not be given access to an electronic copy of the membership list for the other branches. All they have is a once a year printed copy of the list of those members who have agreed to share their contact details with all the other members. The printed list excludes those who asked not to be included from that list as well as anyone who joined since the last list was printed.
I am trying to come up with something that will provide a way for the branch to be able to provide all of the members of the club (well the 40% of members who use the web) with a way to access their branch members only area without the branch having access to a complete membership list.
My current thought is to set up an oauth server but before I spend the time figuring out how to implement it I would appreciate thoughts on whether this is the most appropriate approach or whether there is an easier way of providing a secure mechanism that would allow all members a way to access the branch membership area without the branch having access to a list of all the members outside of their branch.
I would think you could have a “level system” for that members only section of the site, where members of their own branch would be a “member” and those from other branches would be a “visiting member”. You would then allow access accordingly by the user level. If you wish the branch in question could or could not be able to view the list of "visiting member"s who have registered. This branch could also turned on or off the access to log in and registration for these "visiting member"s. To prove that they are already a member of a “branch” the user must be logged in at their current branch to register as a visiting member of the “sharing” branch.
Are these branch committees associated to members in any way? eg. a column in a CSV file or in a database table.
I hope you have great love for this club because if that information isn’t data somewhere I fear you are going to have quite a task in front of you. The more members, the larger the task.
Or are you all set in that regard and more interested in how to isolate the information?
From a data object standpoint, and if I understand the problem correctly, you have two objects. The members and the branches and they are parent->child as in branches->members. If you have that relationship, all you need to do is make sure the calling branch in known and is only allowed to fetch or alter the children members. So, I would say, you’ll need some sort of security token for each branch for your authorization API/ system. That token is stored in the branch object, so when accessing the member data, the owner of that token can only get the child members of that branch.
The current membership system for the main club has a table containing ALL of the members and an access level. The membership office (me) has the top level of access (the site was originally built to make it easier for me to process membership renewals more easily - processing 1200 renewals used to take a huge amount of time), the rest of the main committee has the next level of access and the branch committee members have a similar level of access to the main committee except being limited to the members in their own branch.
One branch has now set up their own members only site. They know who their own members are but they would like to give all the other members access as well but do not have access to a list of who all the other members are (and will not be given a list). So I am looking for a way that they can provide access to their site for all the members without them having access to the actual membership records.
I would do the same thing as s_molinari. If we are talking Read Only a simple public/private key based API would do the job. You could have it up and running in a couple of hours-ish.
The web site I control has a database containing membership records for all 1200+ members of the club.
Those responsible for the other site have access to export the membership details for about 350 of those members. The ones that belong to their branch
They can use that information to grant access to their site to their members but will need to manually transfer new member details across every so often.
They have said that they would like to give access to their site to all members of the club not just those in their branch.
They do not have and are not going to get a complete electronic list of all members of the club. They get a once a year printed list of about 1100 members - the other 100+ not wanting their membership details shared outside of the two committees that need to know who they are.
So I am looking for a way that allows all members the option to access the branch’s site while not giving the branch access to a list of who the members from the other branches are as I am not allowed to give them access to the electronic copy of the membership details of the other branches.
The only way that I have found so far that looks like it can handle this is OAUTH. If I set up an oauth server on the main club site so it has access to the entire membership list and then set up the second site as a registered user of the oauth script then presumably if the branch allows members to login via oauth they will be provided with the necessary token for any member of the entire club to be able to login that way without their site having any information about the members outside of their branch except that their membership number was supplied with a valid token and so that member has successfully logged in and is therefore still a member of the club.
The question is whether there is a simpler way of being able to authenticate members to give them access to the branch site without the branch knowing who all the members are?
I think I’m finally getting a grasp of the situation, please correct me on anything wrong.
The OriginalSite has info about all members.
OriginalSite Members must be registered and log in.
OriginalSite Members are assigned an access level.
The MainCommittee level can access info about all (willing) OriginalSite members.
BranchCommittee level can only access info about their branch’s (willing) members.
.
The BranchSite has info about all it’s branch’s members, but not that of different branch members.
BranchSite Members must be registered and log in.
BranchSite Members are currently not assigned an access level.
The BranchSite wishes to allow all OriginalSite Members access to visit the BranchSite.
The BranchSite wishes to allow all OriginalSite Members access to info about their branch’s (willing) members.
The BranchSite will not have any info about the OriginalSite Members except when they are also members of the BranchSite.
The problem being, the BranchSite needs a way to ascertain that a visitor is a member of the OriginalSite, but can not be allowed to see info about any of the OriginalSite members.
So, you’re thinking that if a login to BranchSite can call OriginalSite to verify OriginalSite membership, that would work.
If all of that is correct, and you can code the BranchSite login, I think you should be able to do an AJAX API type of thing. eg.
Member submits BranchSite’s login form.
AJAX sends form input to OriginalSite API.
OriginalSite API queries database to confirm or reject membership based on sent form input.
If API returns a “valid member status” to the BranchSite, login is allowed.
I have no idea how the branch site is set up as I have no involvement with that. My only involvement is that the branch has asked me to consider providing a way for all members to be able to access their site while keeping everyone else out.
Correct - the most up to date copy of their branch members is on the original site along with the latest information about the members of the other branches. Presumably the branch is extracting an electronic copy of their membership list from the original site every so often to keep their site updated as to who their members are for access.
The issue with this part is not identifying whether a given member exists but verifying whether the person making the request is that member. For example if someone identified themselves as member 8200 (not yet a member, I’ll probably allocate that number later this month or perhaps next month) then the original site can identify that the person is logging in is them because it knows the password hash that the password they need to enter will match but the BranchSite will not know their password in order to confirm whether it is them or someone else trying to gain access by pretending to be them.
You don’t really need OAUTH to do a simple membership verification. But, you do need one of two things.
IF (and a big IF) you trust the branch site and they trust you and the users are logging in on the branch site with the same credentials as on your site and the branch site has the same type of password hashing algorithm you are using too, then, when the user attempts to log in, those credentials are bumped against your database over an API and an “OK” or a “NOT OK” is sent back. If an OK is sent back, then the user can be allowed to enter as a non-branch, but a member of the club, visitor.
OR
You give each user a secret token on your site in their profile page (each token obviously only viewable for each user). They can register at the branch site, but aren’t allowed access to anything except their profile editing page. There, they can enter the token and that token is bumped up against an API to your site. If it passes, the user is allowed access to the branch site. The only issue with this solution is it requires action from the user.
OAUTH or a similar system is a mix of the two points above and resolves the possible security issue of 1 and the possible leak of tokens or the user interaction (copy and paste of token) in 2.
The only thing I don’t get is the hiding of the electronic membership list and that is why I didn’t understand the problem at first. Because, if a good majority of the members go to the branch site and register and can use it, then the branch will automatically have a list of members, which you can’t avoid, not even with OAUTH, because the whole system is a verification that they are proper members. In other words, hiding the electronic list makes no overall sense to me, since you are building a system to verify members on that same list. The branch will know, who is on that list, because they have to grant access. That positive shows they are a member on the list.
I’d look into why you can’t share the electronic list. That would save you a lot of effort, if you could share it. You could still make the api, but only share membership number with possibly some other data from the member. It depends on how safe the API needs to be. You could also do the same with point 2 above, to avoid token leaks as best as possible, but it still isn’t a guarantee someone might abuse the system, which is what OAUTH is about and not for hiding membership verification.
No - they’d have a list of member numbers. There is a lot of personal information stored about each member on the main system which privacy laws do not permit to be shared. The branch has access to all this information about the members who ‘belong’ to their branch because they have signed an agreement regarding the use they will make of it with respect to the operation of their branch and not making any other use of it.
It doesn’t matter whether all of the branches know that member 3733 is a current member of the club or that member and member 7367 is no longer a member but only the branch that a current member belongs to and the committee running the club have access to any additional information about that member unless that member gives permission and then the additional information that is shared is limited to a once a year printed list that only has part of the information.
All the branch needs are two things.
To know whether a given membership number is or is not a current member
That the person requesting access via that membership number is the person that number was issued to.
I do not intend giving any of the branches access to the passwords that the members use to log in to the main site. I do not have control of the security on the branch sites and as the main site stores all of the actual membership data while the branch sites only need to know who the members are to allow access the main site security needs to be higher than that of the branch site.
So the first option will not work as the branch will not have access to the login credentials.
The second solution relies on whoever has built the branch site creating custom code specifically to handle the registration and on my then building code that will interface with their custom code. If one of the other branches decides to set up something similar then their site may not work with the code written by the person responsible for the first branch site. Also I have no idea as to what level of programming ability these people might have or what platform is being used for their sites so they may not have anyone capable of building their part of the custom script using whatever language their site is using.
As another point, I am in the process of setting up additional clubs to run on the same code as this first club. Where those clubs have branches the same situation could arise and so the solution needs to work both for multiple branches of the first club and possible additional clubs. This may never happen, all the other branches and clubs may decide to just put all of the member’s only items inside of the main membership site but I want to at least consider the options before I start building a solution that may need to be adapted to work with a variety of different platforms.
Perhaps as a comparison think of Twitter as the main site and my personal site as the branch site. In this imaginary situation I only want to allow people with a twitter account to access my site. Assuming that Twitter is not prepared to share all of the information about everyone who has an account with them with my site then what mechanisms could twitter provide to allow me to restrict login access to my site to those who have a twitter account that doesn’t share any information beyond the userid and the fact that they are the owner of the account identified by that id?
What’s to stop the branch from requiring real names, or any other information you have in the list, from the user?
Yes, they’d need know the API calls, necessary to connect and use your authorization system, in order to integrate into their authorization system. The API enforces the standard. And the effort on any other site’s part to connect and use the API will be the same no matter what you use, OAUTH or otherwise. OAUTH is just a predetermined API standard for authorization.
If all the users of Twitter would just happen to login into my site through the Twitter authorization API and I request personal data from those users, then theoretically, if they enter the same data, I’d have a list of all the Twitter users and know exactly that they are Twitter users. In other words, this “detail” isn’t important to Twitter. The knowledge of the members in the list is important to you for some reason and that needs looking at.
Nothing but if they want that information they will need to ask the members for it. I was just told that they’d like to make their site available to all members and not just those in their local area who therefore belong to their branch. If I don’t implement anything extra then the only things that they will be sharing with all members are those things uploaded to the main membership site and their site will be limited to just those members they give access to. If I do implement something then all it needs to do is to be able to confirm that the person trying to log in on their site is able to log in on the main site. Since all they are really doing is duplicating part of the functionality already provided on the main site (which could restrict access to members of a particular branch if required) the simplest solution is to get them to upload anything they want to share with all members to the main site. I already have their permission to place copies of their branch magazine there.
The more I look into this the more tempted I am to simply tell them that anything they want to share with all members should be placed on the site where all members already have access to see it.
There would be two login processes but only the one registration process. The only reason for the second login process is that the branch decided to add their own member’s area instead of adding the content to the one that already exists.
The branch have already added their site so those members who have access to it already have two different logins if they want to access both sites.
All new member registrations and renewals must go through the main site either via the member entering their information themselves or by filling out a form and sending it to me for me to process it through the site (only about 40% of the members have used the main site and only 80% have internet access at all).
I do not know the frequency at which the branch intends to bring their membership list for their site up to date with any new members I have processed (even when members do register themselves I still have to assign their membership number and post out their membership kit).
I don’t know how the branch site is loading up their member list but presumably they copied it across at the start and are going to update it from the main site every so often.
We have been using a single registration process for membership for the last 64 years and branch members are defined as those who live in the same state as the branch clubrooms.
Seems to me you are either going to need to put together an API that they will need to figure out how to use on their own, or that you will need to be able to collaborate with their devs (current and future).
Personally, from what I gather of the situation, I’d code up a well documented API
I think that is probably the way to go. It may take quite a while before I can build one though. I still haven’t been able to figure out an appropriate way to have it work. Each approach I have thought of so far has too many security holes in it or would be too complicated to implement easily.
I would create a rest service that accepts the username and branch as parameter returning whether they are on the list or not. In theory you wouldn’t need to protect the service api. However, as an added level of security you *could implement OAuth authentication in front of it to prevent just anyone from hitting the API end point. If it isn’t to much trouble protecting the API via OAuth is probably a good idea but I don’t think a necessity.
