Re: National Student Clearinghouse authentication changes

[Steven Carmody <Steven_Carmody () BROWN EDU>]

At 10:01 AM -0600 11/7/08, Kevin Shalla wrote:
> Now the NSC no longer offers that option, and is requiring us to
> switch to a system where we authenticate the student, then pass the
> SSN in the URL to them.  Apparently now they want us to do their
> authentication for them.  It seems to me that passing the SSN in the
> URL would allow the user to simply modify the SSN in the URL to
> someone else's and then gain access to the information for the
> person with that other SSN.  What are others doing regarding this
> NSC policy change?

Several fall conferences included a presentation describing a current
pilot involving NSC and Stanford Univ. They are using a Federated
approach, based on industry standard security approaches. Both
parties happen to be using the Shibboleth software. However, bottom
line, they are using an industry standard -- SAML 2 -- to exchange
messages containing personal information that MUST be secured -- and
are doing so in a secure and trusted fashion, without exposing the
personal info during transit or in log files. (One hopes that with
the approach that Kevin describes that the NSC web server logs don't
contain the parameters on the url...)

With the federated approach, the campus authenticates the student,
and then provides trusted assertions to NSC (or any other service
provider) to describe the browser user. In NSC's case, this could
include the student's SSN (or perhaps a student ID number would work
as well?). With this approach, the campus would control which
attributes are sent to each service provider (ie the campus will
presumably only send SSN to a very small set of very trusted
partners).

Note that this is a pilot, and there are currently no guarantees that
NSC will take this approach to production. I expect that Conferences
in the spring will include a report out on the status of this pilot,
and describe any future steps.