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.