Resource Account / Credentials Request for 				[[BR]]
UA Enterprise Directory & UA Authentication Service


The information requested below is to enable your service / application to 
- search the UA Enterprise Directory and read more than public data, and/or
- rely on UA Authentication Service to authenticate users and release attributes

1. Your Service Name & URL
    Test (non-production) URL

2. Service/application administrator Name(s)
    Sponsor Name 
    Service email address for notices (preferably not a individual account)

3. Brief narrative of service provided
    Audience (who will use?)
    Anticipated demand in full production (peak logins or queries / hour)
    Service platform (e.g., IIS, Apache, Roxen,…)

4. Authentication method(s) - please refer to "UA Authentication Methods"
https://iam.alaska.edu/trac/attachment/wiki/WikiStart/authN_methods.pdf 

||= Trusted 3rd Party AuthN methods =||=Password relay methods (deprecated)=||
|| SAML (Shibboleth)	||				LDAP - Microsoft AD or ADAM ||
|| CAS			||			 LDAP - EDIR (LDAP v.3)
||  MS-KILE
||  custom SAML
|| MIT Kerberos
|| NTLM
|| !AuthServ (deprecated)

5. Attribute Release:
Attributes requested to be released from the digital identity record of each user:
List each attribute requested with R(ead), S(earch), or C(ompare) access 
(e.g., UA Username S; displayName R; eduPersonAffiliation C)[[BR]]

5.1 For attributes in the Enterprise LDAP Directory (EDIR) see:
https://edir.alaska.edu/cgi-bin/ldap_update_help [[BR]]
5.2 The SAML Identity Provider (Shibboleth IdP) can release other forms of attributes derived from data in EDIR and/or the Unified Domain (AD) including roles and group membership.  Describe any custom attributes to be released to your application based on these data. [[BR]]
5.3 Services that require data on students who have elected confidentiality of their 
educational record must request and receive permission to access this data;
otherwise it will not be available to the service.

6.  You must explicitly acknowledge governance of your use of the issued account / credentials by the resource account security statement attached to this form.  
---------

Resource Account / Credentnials Security Statement[[BR]]
* For reasons of security and privacy, the UA central authentication service and web single sign-on services requires that users authenticate using trusted third party authentication rather than relaying credentials.  Exceptions must be justified by technical limitations of the service and must deploy appropriate audited controlled access to the service and server platform in the UA machine room.  [[BR]]
* Information about an authenticated user can be passed via CAS or SAML to your application upon a user’s successful authentication without needing to query EDIR or AD directly; in these cases no account credentials are necessary for your application to authenticate users or receive attributes about them.  However you will need to establish formal trust between your application and the UA IdP via PKI.  Contact !IAM@Alaska.edu . 
* If your project does require EDIR resource credentials, those credentials are granted for the specific purpose of querying EDIR and not for the purpose of developing "log in" pages to relay UA credentials or otherwise creating duplicate or shadow services provided by IAM.   Development of application specific "log in" pages utilizing EDIR credentials inadequately protects users’ credentials and is strongly deprecated.
* You are responsible for protecting the EDIR resource credentials assigned to your project and the information collected by those credentials (or provided by CAS or SAML).  Resource credentials may not be shared with other departments or groups; it is strongly recommended that all applications rely on their own unique credentials, so that in the case of compromise, the disruption is minimized. 
* Users' credentials, if collected by one of the deprecated credential relay methods, may not be logged or stored on the server or stored in a client-side cookie.
* If any of these requirements to protect users credentials and appropriately use data obtained from the directory are not met, IAM and Security may disable those credentials pending remediation of those defects.
* Should questions arise about the use of credentials by your service or application, you agree to work with OIT’s IAM and Security departments to verify the suitability of your service's processes (e.g., through testing, review of code, and/or a security audit) and correct, as necessary.
Please be assured that IAM strives to make central authentication and assertions of attributes useful, reliable and practical.  Contact !IAM@Alaska.edu with any concerns or problems with our services and we will work with you to resolve them.[[BR]]
Draft 2011-07-18