This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing Mid‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Mid This article has been rated as Mid-importance on the project's importance scale. Cryptography: Computer science Low‑importance This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography Low This article has been rated as Low-importance on the importance scale. This article is supported by WikiProject Computer science (assessed as Low-importance).

This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (September 2010) (Learn how and when to remove this message)

I think the article would do well with a list of known GSSAPI implementors. I could find the following public ones:

• Heimdal[1],
• MIT[2],
• Globus [3],
• Shishi [4],
• SSPI [5] (wire-compat only),
• SAP [6],
  • SAP is not a GSS-API implementation; it simply uses GSS-API SamHartman 21:28, 16 October 2007 (UTC)Reply

but who else? - DLeonard 04:42, 1 October 2006 (UTC)Reply

As for mechanisms, Martin Rex in Nov 2004 wrote to kitten-at-ietf.org with this info:

I was surprized how many independent (mostly proprietary) implementations
of gssapi mechanism exist.  I got to know then only because the vendors
asked for interoperability certification of their product with our
application.  I don't know how many of them (if any) are or have
ever participated in IETF activities.  Here's a quick list of companies:

ietf mechanism:         Company (Country)

   Kerberos 5             MIT, CyberSafe, CA/Platinum, Microsoft, heimdal
   SPKM                   Entrust (CA), Shym (US), Baltimore (US)

proprietary mechanisms:

   AM-DCE                 Bull (FR)
   (propr.)               Sagem (FR)
   sdti,rsakeon,trustnet  TFS-Tech (SE) former RSA/SDTI
   safelayer              Safelayer (SP)
   NEC Secureware         NEC (JP)
   itsec                  UBS/ITsec (CH)
   Adnovum GSSv2          UBS/Adnovum (CH)
   ISign/secui            Penta Security Systems (South Korea)
   Sisler                 Siemens India (India)
   cpro                   Mecomp (RU)
   lissi                  Lissi (RU)
   kobil                  Kobil GmbH (DE)
   T-Secure               secunet/Telekom (DE)

how many do you recognize?

I read the article and noticed several problems that I don't have time to work on now so I decided to document them.

• I don't understand how RADIUSis a competing technology
• I think the proper abbreviation is GSS-API not GSSAPI; see RFC 2743.
• I'm not convinced that impersonationa is incompatible with IETF GSS-API. in particular GSS-API does provide a credential delegation mechanism. The only interisting thing behind impersonation is that you are able to tell the local OS to use the credential for everything including local access checks. For every GSS-API operation you can use the delegated credential just as in Windows. However you need a specific OS call to use that for local operations and that is in fact outside the scope of GSS-API.