cosign-discuss at umich.edu
general discussion of cosign development and deployment
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Central authentication service survey
- To: "cosign-discuss Discussion" <cosign-discuss@xxxxxxxxx>
- Subject: FW: Central authentication service survey
- From: "Drumm, Daniel" <dgdrumm@xxxxxxxxxxxx>
- Date: Wed, 12 Oct 2005 08:33:34 -0400
- Thread-index: AcXO0VKp9IGEnzxqSn24YSi9UV+naQAV6sWg
- Thread-topic: Central authentication service survey
This is from MIT. They state they are looking at Pubcookie
and Yale's CAS. Now might be a good time to remind them of CoSign.
- MIT's response is below:
MIT Kerberos is our primary authentication method and our primary
- What do you use for your central password store
(e.g. LDAP, Kerberos)?
No. We have been able to
leverage many different usage scenarios from our use of single primary Kerberos
- Have you considered the replacement of
your central authentication service, including the central store, with a
different technology (e.g. from Kerberos to LDAP)? Why or why not?
We use a variety of techniques and
- What mechanisms do you provide for
campus application developers to integrate with the central service when the
application cannot interface directly with the chosen technology (e.g. LDAP
proxy for Kerberos, Active Directory integration with MIT Kerberos, web single
sign-on solution, proprietary client solution)?
For example, by using Kerberos and a web application users are
able to obtain a user X.509 certificate. The user certificates are then used for
web authentication in a variety of circumstances including purchasing with
external vendors, access to commercial software, administrative tasks, and
student services. This technology is used by both central services and
We also have some systems that rely on LDAP
authentication. In this case the LDAP server(s) use a module to validate the
supplied username/password with the central KDC. This technique is not approved
for departmental applications. It is only approved when the LDAP server is run
by the same group that is responsible for the KDC operations.
case of Active Directory we primarily rely on the cross realm authentication
provided by the Kerberos protocol. Most users in the central Windows domain do
not know their Windows password. The users initially authenticate to the MIT KDC
to obtain their native Windows tgt and service tickets. We also provide the
ability for the users to set their own native Windows password. This is done so
that applications that only support NTLM can be used by the small population
that uses those limited applications.
We also have some RADIUS based
systems that validate the username/password using the KDC. These systems are
also operated by the same group that is responsible for KDC
There has also been some small scale work done around the use
of HTTP/SPNEGO, which really means that Kerberos is being used for web
As stated in item 3 above, the use of LDAP
authentication is only approved when the application server and LDAP server is
run by the same group that is responsible for the operation of the KDC. We feel
that this substantially mitigates the risk.
- If you are using either LDAP
authentication or an LDAP proxy for Kerberos, how are you mitigating the risk
of password exposure at the application server?
This topic is undergoing active
debate within our organization. We expect that we will expand our web
authentication options in the future. We will likely provide a web loginserver
along the lines of Pubcookie or Yales CAS and use this to support a Shibboleth
- What are the current gaps in your
authentication service offering and how do you plan to address them?
No. We have found no need
of one since Kerberos supports cross realm operations.
- Do you use a password synchronization
service or an enterprise single sign-on solution? Why or why not?
We are not
planning to widely deploy such a service at this time.
- Have you deployed or are you planning
to deploy a dual-factor authentication service? If so, what technology have
We have not
yet completed our elimination of Kerberos 4 on our
- If you have recently completed a
project to eliminate reliance on Kerberos 4, are there any lessons learned you
Special Asst to the VP and Strategic Communications
Services and Technology
Massachusetts Institute of Technology
Massachusetts Avenue Room 10-219
You are currently subscribed to stonesoup@xxxxxxxxx as:
To unsubscribe send an email to
with the word UNSUBSCRIBE as the SUBJECT of the