Date: Tue, 19 Mar 2024 10:51:58 +0000 (UTC) Message-ID: <234075477.1174.1710845518200@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1173_173258993.1710845518197" ------=_Part_1173_173258993.1710845518197 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Research & Scholarship=E2=86=92 (R&S= ) is a global program and standard devised to let scholars and researchers = quickly and seamlessly access a wiki or collaborative research tool at anot= her university or major research facilities like CERN in Switzerland or the= research portal at the National Insitute of Health (NIH) without having to= negotiate the often complicated personal data release procedures on campus= . We all value user privacy and regard its protection as a high priority. A= t a basic level, when a user signs in to a resource via federation, a unive= rsity participating in InCommon might send no personal information beyond t= he minimum necessary to tells the resource: =E2=80=9Cthis person is a legit= imate member of our organization, so please let them in.=E2=80=9D
Alas, for a research collaboration to validate a user=E2=80=99s id= entity in order to grant access to controlled resources, it often needs to = know who the signed-in person is and how to contact that person. That=E2=80= =99s where R&S comes into play. Think of R&S as an optional add-on = to the InCommon infrastructure. When a campus supports R&S, it agrees t= o send a few more bits of information: a person=E2=80=99s name, email addre= ss, and affiliation (e.g. =E2=80=9Cfaculty,=E2=80=9D =E2=80=9Cstudent,=E2= =80=9D and the like) to qualifying research resources. InCommon and sister = federations around the world control which services are added to the pool o= f qualifying R&S services. You can be sure that only legitimate researc= h and scholarship providers receive this additional information.
When your support R&S, when your researcher signs in to a serv= ice offered by, say, NIH, NIH knows who the person is and whether to provid= e access. Back on campus, this gets IT out of the business of having to mak= e a person-by-person decision on whether to send this additional identifyin= g information.
As noted above, many research services require a few additional pi= eces of information to connect a user=E2=80=99s campus credential with acce= ss to the research resources they need. Let=E2=80=99s take a look at XSEDE:= when a user signs into XSEDE via federation for the first time, it uses th= e personal information sent by the campus to establish a user profile. It o= ptionally compares that information with any internal access roster it may = already have, connecting the profile with that roster and grants the signed= -in user the appropriate access. On subsequent sign-in, XSEDE may rely on t= he user information sent by the campus to keep user contact information cur= rent and if appropriate, de-provision access.
This capability is critical to some services=E2=80=99 ability to s= cale support for highly collaborative research projects. Because of it, som= e research services will only allow login if your campus supports R&S.<= /span>
A qualified R&S service is validated and tagged by its registe= ring federation (e.g., InCommon) with an R&S tag. When your campus supp= orts R&S, you are agreeing to configure your federated single sign-on s= ervice to automatically release the relevant user information (for any indi= vidual that may reasonably participate in research collaboration on your ca= mpus) to a service tagged with R&S. In addition, you=E2=80=99d declare = your support for R&S by asking your InCommon site administrator to add = the =E2=80=9CSupports R&S=E2=80=9D tag to your campus information in th= e InCommon Federation.
Here are links to the R&S Entity Ca= tegory specification=E2=86=92 and an FAQ=E2=86=92.= p>
Check to see if your IdP or SP is listed=E2=86=92 as already meeting the Research & Scholar= ship specification.
This wiki page describes h= ow to enable an identity provider (typically a campus single sign-on system= ) to automatically provide the R&S information to R&S tagged servic= es. Your InCommon site administrator can add the R&S tag to your campus= information at the InCommon Federation. Services that qualify can fill out= this application to be given the R&S = tag.
Can't find what you are looking for?