| 5 | | Participation in the InCommon Federation (“Federation”) enables a federation participating organization ("Participant") to use Shibboleth identity attribute sharing technologies to manage access to on-line resources that can be made available to the InCommon community. One goal of the Federation is to develop, over time, community standards for such cooperating organizations to ensure that shared attribute assertions are sufficiently robust and trustworthy to manage access to important protected resources. As the community of trust evolves, the Federation expects that participants eventually should be able to trust each other's identity management systems and resource access management systems as they trust their own. |
| 6 | | |
| 7 | | |
| 8 | | |
| 9 | | A fundamental expectation of Participants is that they provide authoritative and accurate attribute assertions to other Participants, and that Participants receiving an attribute assertion protect it and respect privacy constraints placed on it by the Federation or the source of that information. In furtherance of this goal, |
| | 5 | Participation in the !InCommon Federation (“Federation”) enables a federation participating organization ("Participant") to use Shibboleth identity attribute sharing technologies to manage access to on-line resources that can be made available to the !InCommon community. One goal of the Federation is to develop, over time, community standards for such cooperating organizations to ensure that shared attribute assertions are sufficiently robust and trustworthy to manage access to important protected resources. As the community of trust evolves, the Federation expects that participants eventually should be able to trust each other's identity management systems and resource access management systems as they trust their own. |
| | 6 | |
| | 7 | |
| | 8 | |
| | 9 | A fundamental expectation of Participants is that they provide authoritative and accurate attribute assertions to other Participants, and that Participants receiving an attribute assertion protect it and respect privacy constraints placed on it by the Federation or the source of that information. In furtherance of this goal, !InCommon requires that each Participant make available to other Participants certain basic information about any identity management system, including the identity attributes that are supported, or resource access management system registered for use within the Federation. |
| 17 | | InCommon expects that Service Providers, who receive attribute assertions from another Participant, respect the other Participant's policies, rules, and standards regarding the protection and use of that data. Furthermore, such information should be used only for the purposes for which it was provided. InCommon strongly discourages the sharing of that data with third parties, or aggregation of it for marketing purposes without the explicit permission[1] of the identity information providing Participant. |
| | 17 | !InCommon expects that Service Providers, who receive attribute assertions from another Participant, respect the other Participant's policies, rules, and standards regarding the protection and use of that data. Furthermore, such information should be used only for the purposes for which it was provided. !InCommon strongly discourages the sharing of that data with third parties, or aggregation of it for marketing purposes without the explicit permission[1] of the identity information providing Participant. |
| 36 | | |
| 37 | | |
| 38 | | |
| 39 | | |
| 40 | | |
| | 36 | UA Board of Regents Policy and University Regulation: |
| | 37 | http://www.alaska.edu/bor/policy-regulations/ |
| | 38 | |
| | 39 | UA Student & Enrollment Services documentation on FERPA compliance: |
| | 40 | http://www.alaska.edu/studentservices/ferpa/ |
| 90 | | 2.6 If you support a “single sign-on” (SSO) or similar campus-wide system to allow a single user authentication action to serve multiple applications, and you will make use of this to authenticate people for |
| 91 | | |
| 92 | | ''UA’s central authentication service for web-based applications is not strictly speaking an SSO service; each application requests authentication. However, it is possible to authenticate to the service itself and then launch multiple subscribing services without explicitly re-authenticating. This SSO-like function will not be used for or available to |
| | 90 | 2.6 If you support a “single sign-on” (SSO) or similar campus-wide system to allow a single user authentication action to serve multiple applications, and you will make use of this to authenticate people for !InCommon Service Providers, please describe the key security aspects of your SSO system including whether session timeouts are enforced by the system, whether user-initiated session termination is supported, and how use with “public access sites” is protected. |
| | 91 | |
| | 92 | ''UA’s central authentication service for web-based applications is not strictly speaking an SSO service; each application requests authentication. However, it is possible to authenticate to the service itself and then launch multiple subscribing services without explicitly re-authenticating. This SSO-like function will not be used for or available to !InCommon Service Providers. Session time-outs are not in place. Sessions are terminated with close of browser window(s) for that service. '' |
