| | 1 | {{{ |
| | 2 | #!html |
| | 3 | |
| | 4 | <div class=Section1> |
| | 5 | <p align=center style='text-align:center'><b><span style='font-size:14.0pt;'>INCOMMON |
| | 6 | FEDERATION: PARTICIPANT<br> |
| | 7 | OPERATIONAL PRACTICES</span></b></p> |
| | 8 | <p><span style='color:black'>Participation |
| | 9 | in the InCommon Federation ("Federation") enables a federation participating |
| | 10 | organization ("Participant") to use Shibboleth <i>identity</i> <i>attribute </i>sharing |
| | 11 | technologies to manage access to on-line resources that can be made available |
| | 12 | to the InCommon community. One goal of |
| | 13 | the Federation is to develop, over time, community standards for such |
| | 14 | cooperating organizations to ensure that shared <i>attribute</i> <i>assertions</i> are |
| | 15 | sufficiently robust and trustworthy to manage access to important protected |
| | 16 | resources. As the community of trust |
| | 17 | evolves, the Federation expects that participants eventually should be able to |
| | 18 | trust each other's <i>identity management |
| | 19 | systems</i> and resource <i>access |
| | 20 | management systems</i> as they trust their own.</span></p> |
| | 21 | <p><span style='color:black'>A |
| | 22 | fundamental expectation of Participants is that they provide authoritative and |
| | 23 | accurate attribute assertions to other Participants, and that Participants receiving |
| | 24 | an attribute assertion protect it and respect privacy constraints placed on it |
| | 25 | by the Federation or the source of that information. In furtherance of this goal, InCommon |
| | 26 | requires that each Participant make available to other Participants certain |
| | 27 | basic information about any identity management system, including the identity |
| | 28 | attributes that are supported, or resource access management system registered |
| | 29 | for use within the Federation.</span></p> |
| | 30 | <p><span style='color:black'>Two |
| | 31 | criteria for trustworthy attribute assertions by <i>Identity Providers</i> are: (1) that the identity management system |
| | 32 | fall under the purview of the organization's executive or business management, |
| | 33 | and (2) the system for issuing end-user credentials (e.g., PKI certificates, |
| | 34 | userids/passwords, Kerberos principals, etc.) specifically have in place |
| | 35 | appropriate risk management measures (e.g., <i>authentication</i> and <i>authorization</i> standards, security |
| | 36 | practices, risk assessment, change management controls, audit trails, etc.).<i> </i></span></p> |
| | 37 | <p><span style='color:black'>InCommon |
| | 38 | expects that <i>Service Providers</i>, who |
| | 39 | receive attribute assertions from another Participant, respect the other Participant's |
| | 40 | policies, rules, and standards regarding the protection and use of that |
| | 41 | data. Furthermore, such information |
| | 42 | should be used only for the purposes for which it was provided. InCommon strongly discourages the sharing of |
| | 43 | that data with third parties, or aggregation of it for marketing purposes |
| | 44 | without the explicit permission<a href="#_ftn1" |
| | 45 | name="_ftnref1" title=""><span class=MsoFootnoteReference><span |
| | 46 | class=MsoFootnoteReference><span style='font-size:12.0pt;font-family:"Palatino","serif";"Times New Roman";color:black;'>[1]</span></span></span></a> of |
| | 47 | the identity information providing Participant.</span></p> |
| | 48 | <p><span style='color:black'>InCommon |
| | 49 | requires Participants to make available to all other Participants answers to |
| | 50 | the questions below.<a href="#_ftn2" |
| | 51 | name="_ftnref2" title=""><span class=MsoFootnoteReference><span |
| | 52 | class=MsoFootnoteReference><span style='font-size:12.0pt;font-family:"Palatino","serif";"Times New Roman";color:black;'>[2] </span></span></span></a>Additional information to help answer each |
| | 53 | question is available in the next section of this document. There is also a glossary at the end of this |
| | 54 | document that defines terms shown in italics.<a name="_Ref484143697"></a></span></p> |
| | 55 | <br |
| | 56 | clear=all style='page-break-before:always'> |
| | 57 | <h1><span |
| | 58 | style='color:black'><span>1.<span style='font:7.0pt "Times New Roman"'> </span></span></span>Federation Participant Information</h1> |
| | 59 | <p class=ParaNum2><span>1.1<span |
| | 60 | style='font:7.0pt "Times New Roman"'> </span></span>The |
| | 61 | InCommon Participant Operational Practices information below is for:</p> |
| | 62 | <p class=Infoline>InCommon Participant organization |
| | 63 | name: <u> GENI Project Office </u></p> |
| | 64 | <p class=Infoline>The information below is accurate |
| | 65 | as of this date:<u> August 15, 2011 </u></p> |
| | 66 | <p class=ParaNum2><a name="_Ref491345499"><span>1.2<span style='font:7.0pt "Times New Roman"'> </span></span>Identity Management and/or Privacy information</a></p> |
| | 67 | <p> |
| | 68 | Additional information about the Participant's |
| | 69 | identity management practices and/or privacy policy regarding personal |
| | 70 | information can be found on-line at the following location(s). |
| | 71 | </p> |
| | 72 | <p class=Infoline>URL(s): <u> </u> </p> |
| | 73 | <p class=ParaNum2><a name="_Ref491344385"><span>1.3<span style='font:7.0pt "Times New Roman"'> </span></span>Contact information</a></p> |
| | 74 | <p> |
| | 75 | The following person or |
| | 76 | office can answer questions about the Participant's<i> </i>identity management system or resource access management policy or |
| | 77 | practice. |
| | 78 | </p> |
| | 79 | <p class=Infoline>Name: <u> Tom Mitchell </u> </p> |
| | 80 | <p class=Infoline>Title or role <u> InCommon Technical POC </u> </p> |
| | 81 | <p class=Infoline>Email address <u> tmitchell@bbn.com </u> </p> |
| | 82 | <p class=Infoline>Phone <u> 617-873-3905 </u> FAX <u> </u></p> |
| | 83 | <p class=ParaNum1><a |
| | 84 | name="_Ref491346906"><span>2.<span |
| | 85 | style='font:7.0pt "Times New Roman"'> </span></span>Identity |
| | 86 | Provider Information</a></p> |
| | 87 | <p>The most critical responsibility that an IdentityProvider |
| | 88 | Participant has to the Federation is to provide trustworthy and accurate |
| | 89 | identity assertions.<a href="#_ftn3" |
| | 90 | name="_ftnref3" title=""><span class=MsoFootnoteReference><span |
| | 91 | class=MsoFootnoteReference><span style='font-size:12.0pt;font-family:"Palatino","serif";"Times New Roman";'>[3]</span></span></span></a> It is important for a Service Provider to |
| | 92 | know how your <i>electronic identity |
| | 93 | credentials</i> are issued and how reliable the information associated with a |
| | 94 | given credential (or person) is. </p> |
| | 95 | <p style=' |
| | 96 | page-break-after:avoid'><b><i>Community</i></b></p> |
| | 97 | <p class=ParaNum2><a name="_Ref491346920"><span>2.1<span style='font:7.0pt "Times New Roman"'> </span></span>If you are an Identity Provider, how do you |
| | 98 | define the set of people who are eligible to receive an <i>electronic identity</i>? If |
| | 99 | exceptions to this definition are allowed, who must approve such an exception?</a></p> |
| | 100 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 101 | |
| | 102 | <p class=ParaNum2><a name="_Ref491346932"><span>2.2<span style='font:7.0pt "Times New Roman"'> </span></span>"Member of Community"</a><a href="#_ftn4" name="_ftnref4" title=""><span |
| | 103 | class=MsoFootnoteReference><span><span style='font-size:12.0pt;font-family:"Palatino","serif";"Times New Roman";'>[4]</span></span></span></a> is an assertion that might be offered to |
| | 104 | enable access to resources made available to individuals who participate in the |
| | 105 | primary mission of the university or organization. For example, this assertion might apply to |
| | 106 | anyone whose affiliation is "current student, faculty, or staff."</p> |
| | 107 | <p class=ParaNum2> What subset of persons registered in your identity management system would you |
| | 108 | identify as a "Member of Community" in Shibboleth identity assertions to other |
| | 109 | InCommon Participants?</p> |
| | 110 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 111 | |
| | 112 | <p style=' |
| | 113 | page-break-after:avoid'><b><i>Electronic Identity Credentials</i></b></p> |
| | 114 | <p class=ParaNum2><a |
| | 115 | name="_Ref484143726"><span>2.3<span |
| | 116 | style='font:7.0pt "Times New Roman"'> </span></span>Please |
| | 117 | describe in general terms the administrative process used to establish an |
| | 118 | electronic identity that results in a record for that person being created in |
| | 119 | your <i>electronic identity database</i>? Please identify the<i> </i>office(s) of record for this purpose. For example, "Registrar's Office for |
| | 120 | students; HR for faculty and staff."</a></p> |
| | 121 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 122 | |
| | 123 | <p class=ParaNum2><a name="_Ref491344811"></a><a name="_Ref484143732"><span>2.4<span |
| | 124 | style='font:7.0pt "Times New Roman"'> </span></span>What |
| | 125 | technologies are used for your electronic identity credentials (e.g., Kerberos, |
| | 126 | userID/password, PKI, ...) that are relevant to Federation activities? If more than one type of electronic |
| | 127 | credential is issued, how is it determined who receives which type?</a> If |
| | 128 | multiple credentials are linked, how is this managed (e.g., anyone with a |
| | 129 | Kerberos credential also can acquire a PKI credential) and recorded?</p> |
| | 130 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 131 | |
| | 132 | <p class=ParaNum2><a name="_Ref484143738"><span>2.5<span style='font:7.0pt "Times New Roman"'> </span></span>If your electronic identity credentials require |
| | 133 | the use of a secret password or PIN, and there are circumstances in which that |
| | 134 | secret would be transmitted across a network without being protected by |
| | 135 | encryption (i.e., "clear text passwords" are used when accessing campus |
| | 136 | services), please identify who in your organization can discuss with any other |
| | 137 | Participant concerns that this might raise for them:</a></p> |
| | 138 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 139 | |
| | 140 | <p class=ParaNum2><a name="_Ref491344942"></a><a name="_Ref484143744"><span>2.6<span |
| | 141 | style='font:7.0pt "Times New Roman"'> </span></span>If |
| | 142 | you support a "single sign-on" (SSO) or similar campus-wide system to allow a |
| | 143 | single user authentication action to serve multiple applications, and you will |
| | 144 | make use of this to authenticate people for InCommon Service Providers, please |
| | 145 | describe the key security aspects of your SSO system including whether session |
| | 146 | timeouts are enforced by the system</a>, |
| | 147 | whether user-initiated session termination is supported, and how use with |
| | 148 | "public access sites" is protected.</p> |
| | 149 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 150 | |
| | 151 | <p class=ParaNum2><a name="_Ref484143786"><span>2.7<span style='font:7.0pt "Times New Roman"'> </span></span>Are your primary <i>electronic identifiers</i> for people, such as "net ID," eduPersonPrincipalName, |
| | 152 | or eduPersonTargetedID considered to be unique for all time to the individual |
| | 153 | to whom they are assigned? If not, what |
| | 154 | is your policy for re-assignment and is there a hiatus between such reuse?</a></p> |
| | 155 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 156 | |
| | 157 | <p style=' |
| | 158 | page-break-after:avoid'><b><i>Electronic Identity Database</i></b></p> |
| | 159 | <p class=ParaNum2><a name="_Ref484143794"><span>2.8<span style='font:7.0pt "Times New Roman"'> </span></span>How is information in your electronic identity |
| | 160 | database acquired and updated? Are |
| | 161 | specific offices designated by your administration to perform this |
| | 162 | function? Are individuals allowed to |
| | 163 | update their own information on-line?</a></p> |
| | 164 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 165 | |
| | 166 | <p class=ParaNum2><a name="_Ref484580135"><span>2.9<span style='font:7.0pt "Times New Roman"'> </span></span>What information in this database is considered |
| | 167 | "public information" and would be provided to any interested party?</a></p> |
| | 168 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 169 | |
| | 170 | <p class=SubHeading>Uses of Your Electronic Identity Credential System</p> |
| | 171 | <p class=ParaNum2><a name="_Ref484143813"><span>2.10<span style='font:7.0pt "Times New Roman"'> </span></span>Please identify typical classes of applications |
| | 172 | for which your electronic identity credentials are used within your own |
| | 173 | organization</a>.</p> |
| | 174 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 175 | |
| | 176 | <p class=SubHeading><a name="_Ref484143823">Attribute Assertions</a></p> |
| | 177 | <p><i>Attributes</i> are the |
| | 178 | information data elements in an attribute assertion you might make to another |
| | 179 | Federation participant concerning the identity of a person in your identity |
| | 180 | management system.</p> |
| | 181 | |
| | 182 | <p class=ParaNum2><a name="_Ref484143842"><span>2.11<span style='font:7.0pt "Times New Roman"'> </span></span>Would you consider your attribute assertions to |
| | 183 | be reliable enough to:</a></p> |
| | 184 | <p style='line-height:150%;page-break-after: |
| | 185 | avoid;'>[ ] control access to on-line |
| | 186 | information databases licensed to your organization?</p> |
| | 187 | <p style='line-height:150%;page-break-after: |
| | 188 | avoid;'>[ ] be used to purchase goods or |
| | 189 | services for your organization?</p> |
| | 190 | <p style='line-height:150%;page-break-after: |
| | 191 | avoid;'>[ ] |
| | 192 | enable access to personal information such as student loan status?</p> |
| | 193 | <p class=SubHeading><a name="_Ref484143850">Privacy Policy</a></p> |
| | 194 | <p> |
| | 195 | Federation Participants must respect the legal and |
| | 196 | organizational privacy constraints on attribute information provided by other Participants |
| | 197 | and use it only for its intended purposes. |
| | 198 | </p> |
| | 199 | <p class=ParaNum2><a name="_Ref484685873"><span>2.12<span style='font:7.0pt "Times New Roman"'> </span></span>What restrictions do you place on the use of |
| | 200 | attribute information that you might provide to other Federation participants?</a></p> |
| | 201 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 202 | |
| | 203 | <p class=ParaNum2><a |
| | 204 | name="_Ref484687204"><span>2.13<span |
| | 205 | style='font:7.0pt "Times New Roman"'> </span></span>What |
| | 206 | policies govern the use of attribute information that you might release to |
| | 207 | other Federation participants? For |
| | 208 | example, is some information subject to FERPA or HIPAA restrictions?</a></p> |
| | 209 | <p class=Answerline>N/A (GENI is a Service Provider)</p> |
| | 210 | |
| | 211 | <p class=ParaNum1><span><span>3.<span |
| | 212 | style='font:7.0pt "Times New Roman"'> </span></span>Service |
| | 213 | Provider Information</span></p> |
| | 214 | <p><span>Service Providers are trusted to ask for |
| | 215 | only the information necessary to make an appropriate access control decision, |
| | 216 | and to not misuse information provided to them by Identity Providers. Service Providers must describe the basis on |
| | 217 | which access to resources is managed and their practices with respect to |
| | 218 | attribute information they receive from other Participants.</span></p> |
| | 219 | <p class=ParaNum2><span><a name="_Ref491345847"><span>3.1<span style='font:7.0pt "Times New Roman"'> </span></span>What attribute information about an individual |
| | 220 | do you require in order to manage access to resources you make available to |
| | 221 | other Participants? Describe separately |
| | 222 | for each resource ProviderID that you have registered.</a></span></p> |
| | 223 | <p class=Answerline>For all ProviderID's, GENI requires the |
| | 224 | following attributes: EPPN, affiliations, given name, surname (sn), |
| | 225 | email address (mail), and telephone number</p> |
| | 226 | |
| | 227 | <p class=ParaNum2><span><a name="_Ref491345858"><span>3.2<span style='font:7.0pt "Times New Roman"'> </span></span>What use do you make of attribute information |
| | 228 | that you receive in addition to basic access control decisions?</a></span><a |
| | 229 | name="_Ref484143876"> For example, do you aggregate session access |
| | 230 | records or records of specific information accessed based on attribute |
| | 231 | information, or make attribute information available to partner organizations, |
| | 232 | etc.?</a><a name="_Ref484686262"></a></p> |
| | 233 | |
| | 234 | <p class=Answerline>Attribute information is used to create a user |
| | 235 | profile and to contact individuals if support issues arise. Some |
| | 236 | attribute information (including, but not limited to, name and email |
| | 237 | address) is shared with partner organizations within GENI. Contact |
| | 238 | information (name, email address, telephone number) is used if GENI |
| | 239 | operations staff needs to get in touch with an individual for |
| | 240 | operational support. GENI operations staff includes GENI Project |
| | 241 | Office staff and operations staff at partner organizations within |
| | 242 | GENI but outside the GENI Project Office.</p> |
| | 243 | |
| | 244 | <p class=ParaNum2><span><a |
| | 245 | name="_Ref491345881"><span>3.3<span |
| | 246 | style='font:7.0pt "Times New Roman"'> </span></span>What |
| | 247 | human and technical controls are in place on access to and use of attribute |
| | 248 | information that might refer to only one specific person (i.e., personally |
| | 249 | identifiable information)? For example, |
| | 250 | is this information encrypted?</a></span></p> |
| | 251 | <p class=Answerline>Attributes are accessible only to employees |
| | 252 | with privileged access to the server. Privileged access is granted |
| | 253 | only to GENI Project Office system administrators and a subset of |
| | 254 | the technical staff. Attributes are stored in a database in clear |
| | 255 | text. This database is segregated from other databases. Access |
| | 256 | requires both a shell account on the server and an administrative |
| | 257 | database account.</p> |
| | 258 | |
| | 259 | <p class=ParaNum2><span><a |
| | 260 | name="_Ref491345893"><span>3.4<span |
| | 261 | style='font:7.0pt "Times New Roman"'> </span></span>Describe |
| | 262 | the human and technical controls that are in place on the management of |
| | 263 | super-user and other privileged accounts that might have the authority to grant |
| | 264 | access to personally identifiable information?</a></span></p> |
| | 265 | <p class=Answerline>Only the GENI Project Office system |
| | 266 | administrators and select members of the technical staff are |
| | 267 | granted super-user or other privileged accounts.</p> |
| | 268 | |
| | 269 | <p class=ParaNum2><span><a name="_Ref491345908"><span>3.5<span style='font:7.0pt "Times New Roman"'> </span></span>If personally identifiable information is |
| | 270 | compromised, what actions do you take to notify potentially affected |
| | 271 | individuals?</a></span></p> |
| | 272 | <p class=Answerline>If personally identifiable information is |
| | 273 | compromised, individuals would be contacted directly.</p> |
| | 274 | |
| | 275 | <p class=ParaNum1><span><a name="_Ref484691927"><span>4.<span style='font:7.0pt "Times New Roman"'> </span></span>Other Information</a></span></p> |
| | 276 | <p class=ParaNum2><span><a |
| | 277 | name="_Ref491345683"><span>4.1<span |
| | 278 | style='font:7.0pt "Times New Roman"'> </span></span>Technical |
| | 279 | Standards, Versions and Interoperability</a></span></p> |
| | 280 | <p>Identify the version of Internet2 Shibboleth code release that |
| | 281 | you are using or, if not using the standard Shibboleth code, what version(s) of |
| | 282 | the SAML and SOAP and any other relevant standards you have implemented for |
| | 283 | this purpose.</p> |
| | 284 | <p class=Answerline>Shibboleth Native Service Provider 2.x</p> |
| | 285 | |
| | 286 | <p class=ParaNum2><a name="_Ref484143900"><span>4.2<span style='font:7.0pt "Times New Roman"'> </span></span>Other Considerations</a></p> |
| | 287 | <p>Are there any other considerations or information that you wish |
| | 288 | to make known to other Federation participants with whom you might interoperate? |
| | 289 | For example, are there concerns about the use of clear text passwords or |
| | 290 | responsibilities in case of a security breach involving identity information |
| | 291 | you may have provided?</p> |
| | 292 | <p class=Answerline>None</p> |
| | 293 | |
| | 294 | <br clear=all |
| | 295 | style='page-break-before:always'> |
| | 296 | <h2>Additional Notes and Details on the Operational Practices Questions</h2> |
| | 297 | <p><a name="OLE_LINK8"></a><a name="OLE_LINK7">As a community of organizations willing to |
| | 298 | manage access to on-line resources cooperatively, and often without formal |
| | 299 | contracts in the case of non-commercial resources, it is essential that each Participant |
| | 300 | have a good understanding of the <i>identity</i> and resource management practices implemented by other Participants.</a> The purpose of the questions above is to |
| | 301 | establish a base level of common understanding by making this information |
| | 302 | available for other Participants to evaluate.</p> |
| | 303 | <p>In answering these questions, please consider what you would |
| | 304 | want to know about your own operations if you were another Participant deciding |
| | 305 | what level of trust to place in interactions with your on-line systems. For example:</p> |
| | 306 | <ul type=square> |
| | 307 | <li>What would you need to know about an<i> Identity Provider</i> in order to make |
| | 308 | an informed decision whether to accept its <i>assertions</i> to manage access to your on-line resources or |
| | 309 | applications?</li> |
| | 310 | <li>What would you need to know about a <i>Service Provider</i> in order to feel |
| | 311 | confident providing it information that it might not otherwise be able to |
| | 312 | have?</li> |
| | 313 | </ul> |
| | 314 | <p>It also might help to consider how <i>identity management systems</i> within a single institution could be |
| | 315 | used.</p> |
| | 316 | <ul type=square> |
| | 317 | <li>What might your central campus IT organization, as a <i>Service Provider</i>, ask of a peer |
| | 318 | campus <i>Identity Provider</i> (e.g., |
| | 319 | Computer Science Department, central Library, or Medical Center) in order |
| | 320 | to decide whether to accept its <i>identity</i> <i>assertions</i> for access to |
| | 321 | resources that the IT organization controls?</li> |
| | 322 | <li>What might a campus department ask about the central |
| | 323 | campus <i>identity management system</i> if the department wanted to leverage it for use with its own applications?</li> |
| | 324 | </ul> |
| | 325 | <p>The numbered paragraphs below provide additional background |
| | 326 | to the numbered questions in the main part of this document.</p> |
| | 327 | <p>[1.2] InCommon Participants who manage Identity Providers |
| | 328 | are strongly encouraged to post on their website the privacy and information |
| | 329 | security policies that govern their <i>identity |
| | 330 | management system</i>. Participants who |
| | 331 | manage Service Providers are strongly encouraged to post their policies with |
| | 332 | respect to use of personally identifying information.</p> |
| | 333 | <p>[1.3] Other InCommon Participants may wish to |
| | 334 | contact this person or office with further questions about the information you |
| | 335 | have provided or if they wish to establish a more formal relationship with your |
| | 336 | organization regarding resource sharing.</p> |
| | 337 | <p>[2] Many organizations have very informal |
| | 338 | processes for issuing electronic credentials. For example, one campus does this through its student bookstore. A <i>Service |
| | 339 | Provider</i> may be more willing to accept your <i>assertions</i> to the extent that this process can be seen as |
| | 340 | authoritative.</p> |
| | 341 | <p>[2.1] It is important for a <i>Service Provider</i> to have some idea of the community whose |
| | 342 | identities you may represent. This is |
| | 343 | particularly true for <i>assertions</i> such |
| | 344 | as the eduPerson "Member of Community." A typical definition might be "Faculty, staff, and active students" but |
| | 345 | it might also include alumni, prospective students, temporary employees, |
| | 346 | visiting scholars, etc. In addition, |
| | 347 | there may be formal or informal mechanisms for making exceptions to this |
| | 348 | definition, e.g., to accommodate a former student still finishing a thesis or |
| | 349 | an unpaid volunteer.</p> |
| | 350 | <p>This question asks to whom you, as an <i>Identity Provider</i>, will provide |
| | 351 | electronic credentials. This is |
| | 352 | typically broadly defined so that the organization can accommodate a wide |
| | 353 | variety of applications locally. The |
| | 354 | reason this question is important is to distinguish between the set of people |
| | 355 | who might have a credential that you issue and the subset of those people who |
| | 356 | fall within your definition of "Member of Community" for the purpose of |
| | 357 | InCommon <i>attribute assertions</i>.</p> |
| | 358 | <p>[2.2] The <i>assertion</i> of "Member of Community" is often good enough for deciding whether to grant |
| | 359 | access to basic on-line resources such as library-like materials or websites. InCommon encourages participants to use this <i>assertion</i> only for "Faculty, Staff, and |
| | 360 | active Students" but some organizations may have the need to define this |
| | 361 | differently. InCommon <i>Service Providers</i> need to know if this has |
| | 362 | been defined differently.</p> |
| | 363 | <p>[2.3] For example, if there is a campus recognized |
| | 364 | office of record that issues such electronic credentials and that office makes |
| | 365 | use of strong, reliable technology and good database management practices, |
| | 366 | those factors might indicate highly reliable credentials and hence trustworthy <i>identity</i> <i>assertions</i>.</p> |
| | 367 | <p>[2.4] Different technologies carry different |
| | 368 | inherent risks. For example, a userID |
| | 369 | and password can be shared or "stolen" rather easily. A PKI credential or SecureID card is much |
| | 370 | harder to share or steal. For practical |
| | 371 | reasons, some campuses use one technology for student credentials and another |
| | 372 | for faculty and staff. In some cases, |
| | 373 | sensitive applications will warrant stronger and/or secondary credentials.</p> |
| | 374 | <p>[2.5] Sending passwords in "clear text" is a |
| | 375 | significant risk, and all InCommon Participants are strongly encouraged to |
| | 376 | eliminate any such practice. Unfortunately this may be difficult, particularly with legacy |
| | 377 | applications. For example, gaining |
| | 378 | access to a centralized calendar application via a wireless data connection |
| | 379 | while you are attending a conference might reveal your password to many others |
| | 380 | at that conference. If this is also your |
| | 381 | campus credential password, it could be used by another person to impersonate |
| | 382 | you to InCommon Participants.</p> |
| | 383 | <p>[2.6] "Single sign-on" (SSO) is a method that allows |
| | 384 | a user to unlock his or her <i>electronic |
| | 385 | identity credential</i> once and then use it for access to a variety of |
| | 386 | resources and applications for some period of time. This avoids people having to remember many |
| | 387 | different identifiers and passwords or to continually log into and out of |
| | 388 | systems. However, it also may weaken the |
| | 389 | link between an <i>electronic identity</i> and the actual person to whom it refers if someone else might be able to use |
| | 390 | the same computer and assume the former user's <i>identity</i>. If there is no |
| | 391 | limit on the duration of a SSO session, a Federation <i>Service Provider</i> may be concerned about the validity of any <i>identity</i> <i>assertions</i> you might make. Therefore it is important to ask about your use of SSO technologies.</p> |
| | 392 | <p>[2.7] In some <i>identity |
| | 393 | management systems</i>, primary identifiers for people might be reused, |
| | 394 | particularly if they contain common names, e.g. Jim Smith@MYU.edu. This can create ambiguity if a <i>Service Provider</i> requires this primary |
| | 395 | identifier to manage access to resources for that person.</p> |
| | 396 | <p>[2.8] Security of the database that holds |
| | 397 | information about a person is at least as critical as the <i>electronic identity credentials</i> that provide the links to records |
| | 398 | in that database. Appropriate security |
| | 399 | for the database, as well as management and audit trails of changes made to |
| | 400 | that database, and management of access to that database information are |
| | 401 | important.</p> |
| | 402 | <p>[2.9] Many organizations will make available to |
| | 403 | anyone certain, limited "public information." Other information may be given only to internal organization users or |
| | 404 | applications, or may require permission from the subject under FERPA or HIPAA |
| | 405 | rules. A <i>Service Provider</i> may need to know what information you are willing |
| | 406 | to make available as "public information" and what rules might apply to other |
| | 407 | information that you might release.</p> |
| | 408 | <p>[2.10] In order to help a <i>Service Provider</i> assess how reliable your <i>identity</i> <i>assertions</i> may |
| | 409 | be, it is helpful to <span style='color:black'>know how your organization uses |
| | 410 | those same assertions.</span> The assumption here is that you are or will |
| | 411 | use the same <i>identity management system</i> for your own applications as you are using for federated purposes.</p> |
| | 412 | <p>[2.11] Your answer to this question indicates the |
| | 413 | degree of confidence you have in the accuracy of your <i>identity</i> <i>assertions</i>.</p> |
| | 414 | <p>[2.12] Even "public information" may be constrained |
| | 415 | in how it can be used. For example, |
| | 416 | creating a marketing email list by "harvesting" email addresses from a campus |
| | 417 | directory web site may be considered illicit use of that information. Please indicate what restrictions you place |
| | 418 | on information you make available to others.</p> |
| | 419 | <p>[2.13] Please indicate what legal or other external |
| | 420 | constraints there may be on information you make available to others.</p> |
| | 421 | <p>[3.1] Please identify your access management |
| | 422 | requirements to help other Participants understand and plan for use of your |
| | 423 | resource(s). You might also or instead |
| | 424 | provide contact information for an office or person who could answer inquiries.</p> |
| | 425 | <p>[3.2] As a <i>Service |
| | 426 | Provider</i>, please declare what use(s) you would make of attribute |
| | 427 | information you receive.</p> |
| | 428 | <p>[3.3] Personally identifying information can be a |
| | 429 | wide variety of things, not merely a name or credit card number. All information other than large group |
| | 430 | identity, e.g., "member of community," should be protected while resident on |
| | 431 | your systems.</p> |
| | 432 | <p>[3.4] Certain functional positions can have |
| | 433 | extraordinary privileges with respect to information on your systems. What oversight means are in place to ensure |
| | 434 | incumbents do not misuse such privileges?</p> |
| | 435 | <p>[3.5] Occasionally protections break down and |
| | 436 | information is compromised. Some states |
| | 437 | have laws requiring notification of affected individuals. What legal and/or institutional policies |
| | 438 | govern notification of individuals if information you hold is compromised?</p> |
| | 439 | <p>[4.1] Most InCommon Participants will use Internet2 |
| | 440 | Shibboleth technology, but this is not required. It may be important for other participants to |
| | 441 | understand whether you are using other implementations of the technology |
| | 442 | standards.</p> |
| | 443 | <p>[4.2] As an <i>Identity |
| | 444 | Provider</i>, you may wish to place constraints on the kinds of applications |
| | 445 | that may make use of your <i>assertions. </i>As a <i>Service |
| | 446 | Provider</i>, you may wish to make a statement about how User credentials must |
| | 447 | be managed. This question is completely |
| | 448 | open ended and for your use.</p> |
| | 449 | <br clear=all |
| | 450 | style='page-break-before:always'> |
| | 451 | <h2>Glossary</h2> |
| | 452 | <table border=0 cellspacing=0 cellpadding=0> |
| | 453 | <tr> |
| | 454 | <td width=137 valign=top><p>access management system</p></td> |
| | 455 | <td width=502 valign=top><p>The collection of systems and |
| | 456 | or services associated with specific on-line resources and/or services that |
| | 457 | together derive the decision about whether to allow a given individual to |
| | 458 | gain access to those resources or make use of those services.</p></td> |
| | 459 | </tr> |
| | 460 | <tr> |
| | 461 | <td width=137 valign=top><p>assertion</p></td> |
| | 462 | <td width=502 valign=top><p>The <i>identity</i> information provided by an <i>Identity Provider</i> to a <i>Service |
| | 463 | Provider</i>.</p></td> |
| | 464 | </tr> |
| | 465 | <tr> |
| | 466 | <td width=137 valign=top><p>attribute</p></td> |
| | 467 | <td width=502 valign=top><p>A single piece of information |
| | 468 | associated with an <i>electronic identity |
| | 469 | database</i> record. Some <i>attributes</i> are general; others are |
| | 470 | personal. Some subset of all <i>attributes</i> defines a unique |
| | 471 | individual.</p></td> |
| | 472 | </tr> |
| | 473 | <tr> |
| | 474 | <td width=137 valign=top><p>authentication</p></td> |
| | 475 | <td width=502 valign=top><p>The process by which a person |
| | 476 | verifies or confirms their association with an <i>electronic identifier</i>. For |
| | 477 | example, entering a password that is associated with an UserID or account |
| | 478 | name is assumed to verify that the user is the person to whom the UserID was |
| | 479 | issued.</p></td> |
| | 480 | </tr> |
| | 481 | <tr> |
| | 482 | <td width=137 valign=top><p>authorization</p></td> |
| | 483 | <td width=502 valign=top><p>The process of determining |
| | 484 | whether a specific person should be allowed to gain access to an application |
| | 485 | or function, or to make use of a resource. The resource manager then makes the access control decision, which |
| | 486 | also may take into account other factors such as time of day, location of the |
| | 487 | user, and/or load on the resource system.</p></td> |
| | 488 | </tr> |
| | 489 | <tr> |
| | 490 | <td width=137 valign=top><p>electronic identifier</p></td> |
| | 491 | <td width=502 valign=top><p>A string of characters or |
| | 492 | structured data that may be used to reference an <i>electronic identity</i>. Examples include an email address, a user account name, a Kerberos |
| | 493 | principal name, a UC or campus <i>NetID</i>, |
| | 494 | an employee or student ID, or a PKI certificate.</p></td> |
| | 495 | </tr> |
| | 496 | <tr> |
| | 497 | <td width=137 valign=top><p>electronic identity</p></td> |
| | 498 | <td width=502 valign=top><p>A set of information that is |
| | 499 | maintained about an individual, typically in campus <i>electronic identity databases</i>. May include roles and privileges as well as personal information. The information must be authoritative to |
| | 500 | the applications for which it will be used.</p></td> |
| | 501 | </tr> |
| | 502 | <tr> |
| | 503 | <td width=137 valign=top><p>electronic identity credential</p></td> |
| | 504 | <td width=502 valign=top><p>An <i>electronic identifier</i> and corresponding <i>personal secret</i> associated with an <i>electronic identity</i>. An <i>electronic identity credential </i>typically |
| | 505 | is issued to the person who is the subject of the information to enable that |
| | 506 | person to gain access to applications or other resources that need to control |
| | 507 | such access.</p></td> |
| | 508 | </tr> |
| | 509 | <tr> |
| | 510 | <td width=137 valign=top><p>electronic |
| | 511 | identity database</p></td> |
| | 512 | <td width=502 valign=top><p>A |
| | 513 | structured collection of information pertaining to a given individual. Sometimes referred to as an |
| | 514 | "enterprise directory." Typically includes name, address, email address, affiliation, and <i>electronic identifier(s)</i>. Many technologies can be used to create an <i>identity database,</i> for example LDAP or |
| | 515 | a set of linked relational databases.</p></td> |
| | 516 | </tr> |
| | 517 | <tr> |
| | 518 | <td width=137 valign=top><p style='page-break-before:always; |
| | 519 | '>identity</p></td> |
| | 520 | <td width=502 valign=top><p style='page-break-before:always; |
| | 521 | '><i>Identity</i> is the set of information associated with a specific |
| | 522 | physical person or other entity. Typically an Identity Provider will be authoritative for only a subset |
| | 523 | of a person's <i>identity</i> information. What <i>identity</i> <i>attributes</i> might be relevant in any situation depend on the context in which it is being |
| | 524 | questioned.</p></td> |
| | 525 | </tr> |
| | 526 | <tr> |
| | 527 | <td width=137 valign=top><p>identity |
| | 528 | management system</p></td> |
| | 529 | <td width=502 valign=top><p>A |
| | 530 | set of standards, procedures and technologies that provide electronic |
| | 531 | credentials to individuals and maintain authoritative information about the |
| | 532 | holders of those credentials.</p></td> |
| | 533 | </tr> |
| | 534 | <tr> |
| | 535 | <td width=137 valign=top><p>Identity Provider</p></td> |
| | 536 | <td width=502 valign=top><p><span style='color:black'>A |
| | 537 | campus or other organization that manages and operates an <i>identity management system</i> and offers information |
| | 538 | about members of its community to other InCommon participants.</span></p></td> |
| | 539 | </tr> |
| | 540 | <tr> |
| | 541 | <td width=137 valign=top><p>NetID</p></td> |
| | 542 | <td width=502 valign=top><p>An <i>electronic identifier</i> created |
| | 543 | specifically for use with on-line applications. It is often an integer and |
| | 544 | typically has no other meaning.</p></td> |
| | 545 | </tr> |
| | 546 | <tr> |
| | 547 | <td width=137 valign=top><p>personal |
| | 548 | secret</p> |
| | 549 | <p>(also </p> |
| | 550 | <p>verification |
| | 551 | token)</p></td> |
| | 552 | <td width=502 valign=top><p>Used |
| | 553 | in the context of this document, is synonymous with password, pass phrase or |
| | 554 | PIN. It enables the holder of an <i>electronic identifier </i>to confirm that |
| | 555 | s/he is the person to whom the identifier was issued.</p></td> |
| | 556 | </tr> |
| | 557 | <tr> |
| | 558 | <td width=137 valign=top><p>Service |
| | 559 | Provider</p></td> |
| | 560 | <td width=502 valign=top><p><span |
| | 561 | style='color:black'>A campus or other organization that makes on-line |
| | 562 | resources available to users based in part on information about them that it |
| | 563 | receives from other InCommon participants.</span></p></td> |
| | 564 | </tr> |
| | 565 | </table> |
| | 566 | </div> |
| | 567 | <br clear=all> |
| | 568 | <hr align=left size=1 width="33%"> |
| | 569 | <div id=ftn1> |
| | 570 | <p class=MsoFootnoteText><a href="#_ftnref1" |
| | 571 | name="_ftn1" title=""><span class=MsoFootnoteReference><span class=MsoFootnoteReference><span |
| | 572 | style='font-size:10.0pt;font-family:"Palatino","serif";'>[1]</span></span></span></a> Such permission already might be implied by existing contractual agreements.</p> |
| | 573 | </div> |
| | 574 | <div id=ftn2> |
| | 575 | <p class=MsoFootnoteText><a href="#_ftnref2" |
| | 576 | name="_ftn2" title=""><span class=MsoFootnoteReference><span class=MsoFootnoteReference><span |
| | 577 | style='font-size:10.0pt;font-family:"Palatino","serif";'>[2]</span></span></span></a> Your responses to these questions should be posted in a readily accessible |
| | 578 | place on your web site, and the URL submitted to InCommon. If not posted, you should post contact |
| | 579 | information for an office that can discuss it privately with other InCommon |
| | 580 | Participants as needed. If any of the |
| | 581 | information changes, you must update your on-line statement as soon as possible.</p> |
| | 582 | </div> |
| | 583 | <div id=ftn3> |
| | 584 | <p class=MsoFootnoteText><a href="#_ftnref3" |
| | 585 | name="_ftn3" title=""><span class=MsoFootnoteReference><span class=MsoFootnoteReference><span |
| | 586 | style='font-size:10.0pt;font-family:"Palatino","serif";'>[3]</span></span></span></a> A general note regarding attributes and recommendations within the Federation is |
| | 587 | available here: http://www.incommonfederation.org/attributes.html </p> |
| | 588 | </div> |
| | 589 | <div id=ftn4> |
| | 590 | <p class=MsoFootnoteText><a href="#_ftnref4" |
| | 591 | name="_ftn4" title=""><span class=MsoFootnoteReference><span class=MsoFootnoteReference><span |
| | 592 | style='font-size:10.0pt;font-family:"Palatino","serif";'>[4]</span></span></span></a> "Member" is one possible value for eduPersonAffiliation as defined in |
| | 593 | the eduPerson schema. It is intended to |
| | 594 | include faculty, staff, student, and other persons with a basic set of |
| | 595 | privileges that go with membership in the university community (e.g., library |
| | 596 | privileges). "Member of Community" could |
| | 597 | be derived from other values in eduPersonAffiliation or assigned explicitly as |
| | 598 | "Member" in the electronic identity database. See http://www.educause.edu/eduperson/</p> |
| | 599 | </div> |
| | 600 | }}} |
