AcadmicWorks: scholarship management ​http://www.academicworks.com/
entityId ​https://alaska.academicworks.com/shibboleth-sp SP metadata in InCommon?

Correspondence with AcademicWorks's Matthew Thomas <info@…>: (UA questions, followed by AW replies)

(1) I presume AcademicWorks consumes InCommon metadata automatically; but if not, be aware that we will be 
renewing (changing) our signing certificate that expires in a few weeks, so our metadata will change to reflect
that new signing certificate.

Yes, we actually update our metadata every 5 minutes as we have many Shibboleth integrations, some of which are through InCommon and some of which are standalone implementations.  I would not anticipate any issues as we've had many customers update their certificates as a result of the Heartbleed bug a couple months ago.

(2) Your documentation asks for release of email address.  We can release the standard mail attribute, but this
is in principle multi-valuee.  I’ve found that several services cannot handle a multi-valued attribute, so I can
release a single-valued attribute, encoded as mail if that would aid.  

Yes, please configure your IdP to release a single-value attribute for email.

(3) Some new students will not have any email address in their directory record, in which case that attribute would
not be included in the SAML assertion.  Is that acceptable, or do we need to gin up some value for every single
authenticated user?

If a user doesn't have an email address, that is fine.  You do not need to insert some other value into the attribute statement.  The integration will work fine if there is no email attribute in the assertion.  Email is not required for the integration to work, but we encourage it.  It allows us to have a means to communicate with a user who has logged into your AcademicWorks system prior to her data being imported into AcademicWorks, which includes her email address.

(4) We have multiple choices of unique identifiers for our users.  My usual recommendation is the ID# assigned by
our Banner ERP as this is pretty stable (unlike name-based identifiers, which frequently change).  This attribute
is released as
  name="https://iam.alaska.edu/trac/wiki/IamUaArp#bannerID”  
The exact same value can also be released with scope (@alaska.edu) as
 name="https://iam.alaska.edu/trac/wiki/IamUaArp#uakPersonID" id="uakPersonID"  
or as the draft eduPersonUniqueId (also scoped) as
 name="urn:oid:1.3.6.1.4.1.5923.1.1.1.13"

I do not have or know how to create an attribute with BOTH an OID and (different) SAML2 name. 

Please advise whether you prefer scoped or unscoped attribute, and whether any of those just mentioned
will be acceptable.

BannerID is a common choice amongst our Ellucian/Banner customers.  That will work great.  With respect to the SAML Name and OID, all we need is one or the other.  I apologize if the wording was confusing in the document.  The information you provided is what we needed and we'll be looking for name="https://iam.alaska.edu/trac/wiki/IamUaArp#bannerID” as the unique identifier.  This same ID will need to appear in the import file you send us, and we use the unique identifier as a key to the import file to find the associated user.

(5) Finally, your documentation requests  test accounts to mimic logging in as a student or staff member.
I can easily create such test accounts in our directory and provide the appropriate SAML assertions upon
successful authentication.  But do you need these test accounts to also be in the data feed from our ERP?  
That will take additional coordination if required.

No, we don't need the test account to appear in the import file.  We only need these credentials to fully test that we can authenticate and that we're pulling back the necessary attributes from the SAML assertion.