Damion> I have a large project that I hope someone could provide a
Damion> little guidance on. My organization is, for simplicity sake,
Damion> very unstructured. But I need to be able to authenticate
Damion> people to various resources. Although SSO using things like
Damion> shibboleth make some sense, I'm not sure it will cover
Damion> everything that I need it to do.
Well, I think you're up the creek here. If each campus is so
unstructured, and upper management doesn't want to help force the
issue, then you're toast. The best you're going to be able to do is
define a policy for your central site, and then use the carrot/stick
approach to get other sites to follow along.
Damion> - There is a $central campus, that hosts several services such
as Email, Web Based tools, and Administrative Systems.
Where's the money? Do all campus' use the Admin systems?
Damion> - Some campuses only use our Administrative System, and
Damion> VPN. All other pieces are handled by them internally.
Do your students need to use the VPN or is it just staff?
Damion> - Some campuses only use our Administrative System, and
Damion> VPN. All other pieces are handled by their own third party
Damion> vendor when needed.
These two look like they can be lumped together.
Damion> - Two (soon 3) campuses use our Email, Administrative System,
Damion> VPN and they want to be included into more of our
Damion> systems. However they have restrictions because they are
Damion> partly maintained by their respective state government
Damion> department. For example their network is maintained by govt.
And does this state govt enforce their own naming scheme?
Damion> - A new campus coming soon, will eventually use all of our
Damion> services, but for the foreseeab le future will have split services
Damion> between $central campus and external vendors.
This is the simple case, just make them use your central naming scheme
of all their services.
Damion> - Some campuses do everything themselves.
Damion> - All campuses, could potentially have a student using any of
Damion> the $central system depending on need. - Naming schemes are
Damion> different amongst all campuses.
This is where the path to madness lies. And where the problem becomes
political, and not technical. I've been through this when I was with
a company that got bought out by Lucent. We were eventaully forced to
migrate into their scheme called "handles".
- Basically, usernames were globally unique in the first 8 or 14
characters.
- Handles couldn't be re-used for two years after someone left the
company.
- HR, with input from the managers/incoming people chose the handle.
- The user could ask for 1 handle change.
- Marriage/Divorce/etc were allowed of course.
Everything else, in terms of HOW they were managed, was left up to the
individual sites. Esp since we have 120,000+ handles at one point,
and Solaris only allowed 65,000 accounts on one system, you had to
have some segmentation.
Damion> The only unifying thing between all of the campuses is that
Damion> the name on the front door is $COMPANY at $CAMPUS. At present
Damion> their is no plan to fully integrate systems, business
Damion> processes etc. Each campus is allowed to define how they want
Damion> to do things. So there is a possibility that a campus may come
Damion> to the $central campus and ask for everything to now be
Damion> maintained by central, at any time.
To put it bluntly, you're hosed. Get management buy-in, look for
where the money/HR/liability goes, and work with them to fix this
issue.
Damion> My goal is to define some kind of Identity management that
Damion> will allow us to maintain this mess, with as few quirks as
Damion> possible. I want to be able to issue a person an ID no matter
Damion> where they 'live' and have it usable despite their campus
Damion> policy. Their credentials shouldn't change based on who
Damion> maintains the auth server that month. I realize that I may
Damion> not be able to handle absolutely everything, but I at least
Damion> want to have an idea how to integrate existing campuses as I'm
Damion> sure it's a matter of when not if.
If you just have a central registry, which is managed by HR/Registrar,
then you should be all set. The other campus' don't have to use it,
but since all the central Admin/VPN/whatever stuff will, they will
have the incentive to follow allong.
Damion> We don't have Active Directory at $central, yet. We do have
Damion> LDAP which has to be revamped anyway. I am not sure yet how
Damion> our other campuses do their authentication and I really have
Damion> no influence in respect to most of them. Most will not be able
Damion> to maintain their own Directory, even if they were convinced
Damion> that they needed one.
Don't worry about the technical means yet, just worry about the
process and how to make it so that it's unique. Since you're a
school, have it all run by the people who either write the paychecks,
or those who collect tuition money from students. Then if a student
doesn't pay, their handle gets disabled (not deleted!) centrally.
Make this central handle registry available easily to all the other
sites.
Do you have any coordination for student IDs? Can you leverage that
instead?
Damion> And as with every project of this complexity, there is no budget for it.
Bwah hah hah! Actually, once you can show them how they'll save money
by going with your system, then you're golden. Again, get the
Registrar and those who collect money involved in the process, since
that's where the savings will come from.
Damion> The way that it has been handled in the past is just to give
Damion> any external campus user a $central account. But we have
Damion> naming conflicts, no way to verify if a person still exists
Damion> automagically, and just general confusion about who is
Damion> who. For example Joe Cool is really an employee at $campus[4],
Damion> but he has a jcool @ $central[0] account so that he can access
Damion> the admin system. Too bad there is also a Joe Cool that works
Damion> at $campus[0] as well, with no relation to the other.
At this point, you don't care. Just define the central process, push
it out to as many sites as you can, and wait for the others to see the
benefits of using your model.
Damion> I'm currently looking at slapd-meta option for OpenLDAP which
Damion> seems like it will allow for some of this (not many examples
Damion> out there). However if anyone has any ideas, suggestions or
Damion> offers of Beer, I'm all ears.
It honestly sounds like a great project, but the politics are the
killer. Again, find the money people and bring them onboard first and
you'll be halfway there. Give them easy access. Automate it so that
handles/accounts are disabled in the central DB by them, not you.
Then pull updates from *that* system o your Admin, VPN, remote
campuses, etc.
You'll need to problably have a mapping of:
userid
First/Middle/Last
campus
ssn (scary!)
status (one of faculty,student,staff,other)
created date
disabled date
Where the tuple of (userid,campus,status) is the unique key. I assume
a faculty at one campus can be a student elsewhere.
John
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
