Just fishing before I call NHQ, but does anybody know if the IT folks at HQ have any sort of directory implementation (ie. LDAP) for remote authentication of membership? I'm trying to find a way not to duplicate effort with my unit website/intranet, and LDAP-type authentication would be key in keeping me from creating individual user IDs, and we could use a first initial / last name user ID, or something...
Thanks
I would actually be intersted in hearing what you find out.
Ande Boyer, ALWG IT Officer, imports ALWG members' ID from WIMRS I believe. He's a member on the forum here so you may want to contact him and see how he has arranged it with NHQ.
Good call. I'm trying to avoid going the whole "import members" route, but that would truly be the most "non invasive" way.
What we're doing is setting up an area within our Content Management System that will be for 'members only' so that FOUO-type data (rosters, mostly) are at least under some modicum of control and security.
Importing members and forcing them to use, say, their CAPID as the password is one method (or at least, setting the inital password to their CAPID), but then it starts to fall flat when we get new members, transfers, etc. Plus then my IT guy has to do work when new members join, what if he's out for a week, or he batches them up, whatever.
If NHQ was smart, they'd port the memebership database into some sort of a directory format and allow an x.500-like access for authentication. LDAP, of course, is the TCP/IP oriented version of that. In that way, NHQ maintains the authoratative database, since they're the ones who ultimately know when someone is "joined" or "not joined," "renewed" or "not renewed," etc. Avoids duplication of data.
How does Pete Andersen do it for the WMU?
Might wanna ask him.
Yeah, serving LDAP from the e-Services user DB would be just delightful. Create a profile once at National and it works "everywhere LDAP products are sold! (tm)" And not only for a directory perspective, but allow LDAP binding for password authentication so your e-Services user/pwd becomes the only login you ever need. Whee!
Quote from: NIN on January 14, 2007, 01:16:07 AMIf NHQ was smart, they'd port the memebership database into some sort of a directory format and allow an x.500-like access for authentication. LDAP, of course, is the TCP/IP oriented version of that. In that way, NHQ maintains the authoratative database, since they're the ones who ultimately know when someone is "joined" or "not joined," "renewed" or "not renewed," etc. Avoids duplication of data.
Any guesses on how few of those words the CAP IT team actually understood? Remember, "Alabama .NET programmers" is an oxymoron! :o 8)
I'm with Justin, CAP I'd be willing to bet, that between the HAM geeks and computer nerds (I'm the latter), CAP has more technology professionals
by percentages than most volunteer orgs, and yet anyone who has seen the WMU, eServices, or even CAP.gov knows no will listen to them.
Useless nonsense like p.25? SURE!
Spend 15 minutes reading "GUI Design for Dummies"?
Who has time for that.
NIN, you're asking for something they can't even comprehend, let alone be interested in implementing.
At one point...during my days working on the IT specialty track I proposed such an idea will less then enthusiastic feedback. I figured LDAP would be the perfect solution to what you are trying to propose. Maj. Williams (RMR) and I discussed doing one for the units we work for (RMR and NYC Group). The major limitation was updating the directory when personnel changes occur. Thus, it never made it including the staff. I would love to hear some ideas on how to accomplish this.
The best thing I could recommend, assuming NHQ doesn't want anything directly touching the membership database, is a daily relational query of e-Services accounts (with limited data -- e-Services username, password, display name, member type / rank, charter info, etc... nothing under privacy act) for all active members to an LDAP server. If you're not an active member, your e-Services info doesn't get passed over to the dump and therefore you cannot authenticate to any application being served by LDAP. Conversely, however, if you create a new account on e-Services, you must wait for the next dump before you can access any applications served by LDAP (but hey, what can ya do?)
A daily/nightly (2x per day?) dump from the membership database/eServices authentication database to an LDAP server would be grand. When your status changes, its 12-24hrs max before an update occurs.
Then again, how hard is it to query the DB for LDAP calls? Probably too much overhead.
I'm not sure it's quite that simple. Getting NQH to not only sign off on the project but to get them to write the routines needed to create an LDIF file from. I'm not sure the code is all that tough if it were well thought out.
Technically speaking, I think the way to do it would be to create routine in e-services to append all the changes we would need (CAPSN, unit, rank, email, position...?) to an LDIF file when they are updated. Simply have the LDAP server retrieve and the file twice a day and purge after successful update.
That said, I don't the technical limitations are the problem. On the other hand if we were to thing large scale maybe we can get all of eservices moved to an LDAP server. Custom schema's could handle most CAP items and if you needed extended functionality you could use a relational database and use LDAP for the authentication....eh, forget I mentioned that.
I of course, love the idea and would be willing to work on something if we can iron out the maintenance issue.
Quote from: NIN on January 16, 2007, 06:55:08 AM
A daily/nightly (2x per day?) dump from the membership database/eServices authentication database to an LDAP server would be grand. When your status changes, its 12-24hrs max before an update occurs.
Then again, how hard is it to query the DB for LDAP calls? Probably too much overhead.
It's not "hard". There are two concerns -- the first, like you mentioned, being the overhead and just heavy loading on the DB server from queries in general. The second is the paranoia associated with having those queries touching a DB with privacy act data in it.
I know that a well designed query system could touch the DB without any problems, but just like I know from work, some people don't even want to risk it.
I think, by far, the largest problem will be getting NHQ to not only understand what the idea is, but to get them to sign off on it. It seems to me that when it comes to cutting edge, open source technology - they are a little hesitant to make any of those changes. I'm pretty sure the WMU does an auto-sync to the NHQ DB about once per day, which is what we're talking about. The problem is that the WMU uses the same back-end system (I think), so the translation is minimal.
Someone correct me if i'm mis-informed.
SW
This gets into the idea that NHQ could offer, as a service to members/units/the field, an intranet-like portal. Remote authentication is part of the way to get there.
eServices goes a long way toward this kind of thing, but there is only NATIONAL information there. If everytime one of my members logged into eServices he or she saw "Welcome to the Concord Composite Squadron's Intranet Home Page" and included a number of things:
1) A unit calendar with the capability to drill into an event and see what that event is.
2) Ability to turn on/off "higher HQ" layers on the calendar.
3) Ability to email/contact members from within the interface.
4) Modules for things like eServices connections, online tests, unit news, etc
That would improve member communication and ease administrative burden. I'm working on doing the functional equivalent of this now, on my own server space, with our own user database.
Hell, I just looked at Google Tools for Domains..
No reply from Michelle Yost yet about LDAP. I sent my message yesterday morning, so I'm sure they're picking up the pieces after the weekend.
Quote from: NIN on January 17, 2007, 04:26:52 PM
This gets into the idea that NHQ could offer, as a service to members/units/the field, an intranet-like portal. Remote authentication is part of the way to get there.
eServices goes a long way toward this kind of thing, but there is only NATIONAL information there. If everytime one of my members logged into eServices he or she saw "Welcome to the Concord Composite Squadron's Intranet Home Page" and included a number of things:
1) A unit calendar with the capability to drill into an event and see what that event is.
2) Ability to turn on/off "higher HQ" layers on the calendar.
3) Ability to email/contact members from within the interface.
4) Modules for things like eServices connections, online tests, unit news, etc
That would improve member communication and ease administrative burden. I'm working on doing the functional equivalent of this now, on my own server space, with our own user database.
Hell, I just looked at Google Tools for Domains..
No reply from Michelle Yost yet about LDAP. I sent my message yesterday morning, so I'm sure they're picking up the pieces after the weekend.
Heck, while we're making a wish list of this sorts, and since you mentioned emailing members from that "portal" of sorts, why not automagically create with the "e-services" account creation a member email address: john.doe@members.cap.gov or some such? Those who don't want to check webmail can set it up as an automatic forwarder to something they do check, or if I'm really dreaming, a POP3 server. :o
Lends more credibility to official emails, too, if you need to send to outside agencies, the media, etc.
BTW, I did hear back from Michelle, and the long and the short of it is that there is no external authentication of any sort, in part, due to concerns about information security with the auditors, etc. There is a worry (and I think its relatively accurate) about passing password data back and forth during LDAP queries.
They do have some things "in the hopper" down there, however, but the event horizon is quite long.
Well, that's why you use secure LDAP. Duh. :) Nah, I understand the real problem is in masqueraded applications that capture and exploit user authentication credentials... and there really is no way around that unless the site gets a server certificate signed by NHQ, but then the user has to be sharp enough to verify they're on a site with a legitimate certificate before they use their credentials.
So how far away was that event horizon?
Close to 4 years from your request and your request seems as valid today as it was then... Maybe even more so...
Is the event something like local level data, like rosters, available on eServices?
I had started on a process to allow the non-technical to upload the CAPWATCH.mdb file to a website and have it update the user roster in the site. Then NHQ dropped the .mdb format :-[. I think most of what you have described could be done with the members.txt file. Updating could be done by a wider number of computer literate members vs. the IT amature / pros. If anyone is interested I could dig up the code. (Java based)