Single Sign-On with GRID Certificates Ernest Artiaga (CERN – IT) GridPP 7 th Collaboration Meeting July 2003 July 2003

Outline Motivation and goals Motivation and goals Authentication mechanisms Authentication mechanisms Implementing web single sign-on Implementing web single sign-on Mapping certificates to accounts Mapping certificates to accounts Providing certificates to users Providing certificates to users Current status Current status Summary and conclusions Summary and conclusions

Motivation and goals The GRID environment offers: The GRID environment offers: A lot of computing power A lot of computing power The possibility to execute big and complex applications The possibility to execute big and complex applications But GRID users will also need basic services: But GRID users will also need basic services: Mail Mail Web Web Access to administrative procedures Access to administrative procedures We want to integrate the services for GRID and local users We want to integrate the services for GRID and local users Cross-platform authentication Cross-platform authentication Single sign-on Single sign-on

Authentication mechanisms PKI/Certificates PKI/Certificates Off-line authentication Off-line authentication Someone (CA) signs a document saying who I am Someone (CA) signs a document saying who I am The service verifies the signature The service verifies the signature Used across platforms Used across platforms Standard extension mechanisms Standard extension mechanisms Kerberos tickets Kerberos tickets On-line authentication On-line authentication Someone (KDC) tells the service that I am really who I claim to be Someone (KDC) tells the service that I am really who I claim to be Intra-site security mechanism (used by Unix and Microsoft) Intra-site security mechanism (used by Unix and Microsoft)

Implementing single sign-on Users coming from GRID and local Unix and Windows environments Users coming from GRID and local Unix and Windows environments Services are multi-platform (Unix/Windows) Services are multi-platform (Unix/Windows) Logon and Authentication mechanisms are different Logon and Authentication mechanisms are different A user must type his/her credentials again and again A user must type his/her credentials again and again Solution? Solution? We will focus on web services We will focus on web services

Single sign-on via web The user must provide a valid PKI/Certificate We must trust the web server: it will impersonate the user! Complex scenario: many possibilities Web Server User Services

Impersonation in Apache/Unix Direct impersonation via Certificates Direct impersonation via Certificates Privileged server Privileged server DB to map certificates into accounts DB to map certificates into accounts The service runs as the user owning the certificate (login) The service runs as the user owning the certificate (login) Impersonation via Kerberos ticket Impersonation via Kerberos ticket The service acquires the user ticket to access the resources The service acquires the user ticket to access the resources It should get Kerberos ticket from the certificate It should get Kerberos ticket from the certificate May use extra software: Kerberos leveraged PKI May use extra software: Kerberos leveraged PKI KCT (Kerberos Certificate Translation) KCT (Kerberos Certificate Translation) Mod_KCT (Apache module) Mod_KCT (Apache module)

Impersonation in MS web servers Based on the Windows Identity Mapping mechanism Based on the Windows Identity Mapping mechanism Maps a certificate to a Windows account (logon) Maps a certificate to a Windows account (logon) The identity mapping is set in the Active Directory The identity mapping is set in the Active Directory Common for the whole domain Common for the whole domain Provides an internal ticket Provides an internal ticket Allows accessing windows resources Allows accessing windows resources

Windows identity mapping Two flavors: manual and automatic Two flavors: manual and automatic In manual mapping, the administrator must specify which certificate maps into which account (can be done programmatically) In manual mapping, the administrator must specify which certificate maps into which account (can be done programmatically) In automatic mapping, the certificate must contain an extension with the User Principal Name (UPN) of the account In automatic mapping, the certificate must contain an extension with the User Principal Name (UPN) of the account No explicit mapping is needed No explicit mapping is needed Originally designed for smart cards Originally designed for smart cards

Integrating external GRID users Local account for GRID users? Local account for GRID users? Users not registered locally, but having valid GRID certificates Users not registered locally, but having valid GRID certificates How to handle them (Unix/Windows)? How to handle them (Unix/Windows)? Validate the certificate Validate the certificate Create account on-the-fly Create account on-the-fly Assign new user to appropriate groups Assign new user to appropriate groups Map the certificate to the new account Map the certificate to the new account Delete the account at user logout Delete the account at user logout

So far… Web services can be configured to use certificates for authentication Web services can be configured to use certificates for authentication We should be able to use GRID certificates to access these services We should be able to use GRID certificates to access these services Possibly adding some extensions Possibly adding some extensions …Now we need to integrate the local users …Now we need to integrate the local users How can we easily provide them with certificates ? How can we easily provide them with certificates ?

Providing certificates to users GRID users already have a certificate GRID users already have a certificate The others… The others… At CERN, both local Unix and Windows users receive a Kerberos ticket during logon At CERN, both local Unix and Windows users receive a Kerberos ticket during logon We can issue a PKI/Certificate from a Kerberos ticket We can issue a PKI/Certificate from a Kerberos ticket KCA (Kerberized CA) KCA (Kerberized CA)

Integrating non-GRID users Kerberos Leveraged PKI Kerberos Leveraged PKI Credentia l Cache Login KDC KCA Browser LibPKCS11 Web Server

Tools KCA (Kerberized CA) supports Kerberos V (Windows 2000 compatible) KCA (Kerberized CA) supports Kerberos V (Windows 2000 compatible) KCA clients are available for Unix and Windows KCA clients are available for Unix and Windows PKCS11 library (smart card emulation) is also available for Unix and Windows PKCS11 library (smart card emulation) is also available for Unix and Windows

Issues Interoperability puts extra requirements in the certificates Interoperability puts extra requirements in the certificates Specific extensions Specific extensions Revocation lists Revocation lists … It depends on many components It depends on many components Some of them not completely stable or ready for production Some of them not completely stable or ready for production The server must be able to The server must be able to Accept the certificate Accept the certificate Identify the account to which the certificate refers Identify the account to which the certificate refers

The integrated view Linu x Box Windows 2000 KDC Linux KCA OpenSSL CA Web Browser Lib PKCS11 Windows 2000 IIS 5.0 AD Resources Certificate Template Win Box Unix Apache Mod_KCT KCT MIT KDC GRID Certificates

Summary and conclusions It is possible It is possible To integrate GRID and local infrastructure services To integrate GRID and local infrastructure services Provide cross-platform Single Sign-on using GRID authentication mechanisms (i.e. PKI/Certificates ) Provide cross-platform Single Sign-on using GRID authentication mechanisms (i.e. PKI/Certificates ) But full functionality has issues… But full functionality has issues… Lots of components involved (KDC, KCA, AD…) Lots of components involved (KDC, KCA, AD…) Compatibility (not fully documented requirements) Compatibility (not fully documented requirements) Is the complexity worth while? Is the complexity worth while? Over-complex for a reliable service today Over-complex for a reliable service today But the components are being used/developed in other areas But the components are being used/developed in other areas

Summary and conclusions Nevertheless, it is an interesting mechanism Nevertheless, it is an interesting mechanism Web services are widely spread Web services are widely spread Can be shared by GRID and non-Grid users Can be shared by GRID and non-Grid users Smooth transition from non-GRID to GRID Smooth transition from non-GRID to GRID Partial functionality is possible and ready to work Partial functionality is possible and ready to work Mapping long term certificates Mapping long term certificates Some of the tools are being actively developed Some of the tools are being actively developed Weve heard of some related success stories Weve heard of some related success stories

Questions?