The Challenge. The goal of our service is to allow users’ credentials as managed by universities (and other research institutions) in InCommon to be used to access NSF’s cyberinfrastructure. The primary technical challenge we face is the technology difference between InCommon, which is based on the Security Assertion Markup Language (SAML) as implemented by the Internet2 Shibboleth software, and NSF’s cyberinfrastructure, which is based on public key infrastructures (PKIs) that emerged from computational grids.

Our Approach. Our project will leverage existing software to provide the required functionality. Much of our approach has been demonstrated in the TeraGrid federated login system. Since Shibboleth is a web-based technology, designed for users using web browsers, our service will be primarily a web application residing in Apache. Building on Shibboleth and Apache, we will use the work pioneered in the GridShib project, deployed in TeraGrid, to convert Shibboleth into the PKI credentials needed for much of the NSF CI. As with the TeraGrid work, we will use MyProxy with specialized hardware security modules to generate these credentials.

Service Operation. Central to our proposed work is the operation of our service for the NSF community. Our plans for operating our service include:

• 24x7 Support
• Strong Operational Security
• Incident Response and Certificate Revocation
• Reliability, Disaster Recovery and Scalability
• Detailed Usage Accounting

Level Of Assurance. Standard membership in InCommon provides limited guarantees regarding the level of assurance of user credentials. However, InCommon has now defined "Bronze" and "Silver" Identity Assurance Profiles to which members may adhere in order to provide higher-levels of assurance. Both the standard level and Silver level will be of use to the NSF community. (We don’t believe the NSF CI community has a current need for the Bronze level.) The default level will initially be much more common while Silver will take some time for universities to adopt, but Silver offers a higher level of assurance desired by some CI projects. We will operate two certification authorities (CAs): one for standard InCommon members and one for those meeting the Silver profile. CI operators will then be able to choose to trust one or both of these CAs based on their desire for assurance and the breadth of their user base. We believe that ultimately the Silver profile is more desirable for NSF CI due to its higher security and will work in our outreach activities to encourage its adoption. The International Grid Trust Federation (IGTF) is the de facto standards body for defining levels of assurance for PKIs in production academic grids around the world. We will pursue IGTF accreditation for the "Silver" CA, making those credentials usable for CI with high need for assurance.

Non-InCommon institutions. While InCommon is growing and represents over 100 universities and over 3 million users, we recognize that there will be users not represented by InCommon. While we expect this problem to decrease with time as more universities join InCommon, we will provide these users with an alternative mechanism for using our service so they are not left out. That alternate mechanism will be to leverage the free identity provider service called ProtectNetwork. This will allow users at universities not in InCommon to use our service in the same manner.

Privacy. The CILogon service will follow best practices for auditing, as befits an authentication service. With regards to these logs, we will follow NCSA and University of Illinois policies that we utilize today with our other PKIs. In summary, user information will only be released in aggregate form (so we can report metrics to NSF) or with the explicit, opt-in permission of the user.

Host credentials. Operators of grids will know that while user credentials are the majority of the credentialing workload, services also need credentials. We do not believe trying to tackle service credentials is a problem well served by our CILogon system since it would require a set of checks for determining what users are truly authorized for what services that would greatly complicate the service.