|
|
|
www.ASPonline.com |
ASP Forum
Turning Off Passwords
"How can we tell when to disable password access to our Web
support site? We're setting up a new support portal, and we
don't like the idea of leaving it up to the customer to tell
us that a contact has left the company or moved to a new
position. Any suggestions?"
—Gerry from Georgetown
Gerry,
I agree with the previous comments (see below) and if Keith
doesn’t mind, I wanted to add a few as well.
Judging from this question, access to your support system appears
to be dependent on a valid customer contract and verification is
the responsibility of your team. As you have discovered, one way
to effectively manage this process is to involve the customer.
Understanding this, you may want to consider tying web access to
the support contract by way of an identifier (contract number for
example). If this association is possible you could assign
administrative privileges, by contract (or identifier) to one or
more company employees (multiples are preferred to ensure
coverage). After the administrative account is created it would
be the responsibility of that customer delegate to approve and
manage access for their respective teams. No one would be able to
access your web support system using a customer’s credentials
without the consent of their user administrator(s).
Providing your customers with a way to manage their support
activities shifts this burden away from your team and to the
customer — where it should be. This methodology adds
flexibility and provides a certain level of autonomy which can
actually add value to the customer experience.
I realize that there are numerous considerations and caveats
however; this is merely a “food for thought” suggestion.
—David Bettenga
Sr. Manager, Partner Support Operations
Oracle
david.bettenga@oracle.com
Dear Gerry,
- Vote them off the island! — allow people in the same
email domain (except hotmail, gmail, etc) to see each other.
Allow any 2 to vote someone out.
- Delegate an account admin (again per email domain) —
give that person special rights to manage accounts. Ideally
there should be 2 in case one leaves.
- Periodically scrub for inactive accounts — send a
warning email, with a link which will record them as logging in.
If another (pick time period) goes by — delete (or
better inactivate) the account.
- Set up formal federations between authentication domains
(possible in theory — I’ve never heard of anyone doing it
in practice). So you auth people against the customer/partner
LDAP (or other auth facility) — if their auth says OK,
you trust the user.
I am not aware of anyone that claims to do this well. In
practice, I’ve only used 2 and 3. I think 1) has some potential
to be most useful, particularly as social-media emerges.
—Keith Redfield
Director, Global Support Technology
Juniper Networks
kredfield@juniper.net
[If you have any other suggestions, please send an
email to membership director Jane Farber at jfarber@asponline.com,
and we'll post your feedback.]
|
|
|
