...
We have configured the new Confluence and Jira sites to allow anyone using an email address from a non-public domain to request access via Atlassian's standard workflow. Any routine request for access will generally be approved, and access to the site includes the ability to comment or add/edit pages, create issues, etc. Any contributor posting to the wiki or creating an issue agrees to license their provided content under the same license noted above.
...
All code/patches submitted to the issue tracking service must be licensed under the Apache License, version 2 or otherwise contributed to the Shibboleth Project per the terms set out by the project’s Contribution Policy.
Member Support Desk
Pending the final migration, member support is still being managed via the old Jira Service Desk system; for ease of migration in the new future, Member support has also been migrated to the Jira Cloud tenant and http://support.shibboleth.net is the best method to use to access that platform.
Federated Access
The older hosted platform is SAML-enabled, and members seeking support will need to log in via an acceptable IdP. The IdP must release:
a required unique identifier for the user (see below)
displayNameif the user wishes to have a human-readable name suitable for display or searchmailif the user wishes to receive notifications (e.g., changes in issue status or updates to wiki pages) via email
Note that users may modify their profile name or email address, but it will be reset to an IdP-supplied value each time they login.
The preferred identifiers supported include the legacy eduPersonPrincipalName attribute and the newly-proposed SAML subject-id attribute. The latter is ideal if a name and email address are included, while EPPN is best if provided by itself because of the strong need to publically identify contributors in these collaborative tools.
If use of a public identifier is a problem due to privacy restrictions, we tolerate use of the newly-proposed SAML pairwise-id attribute, but we do not encourage it. For historical reasons, we do support the legacy pairwise identifiers that fall under the eduPersonTargetedID and SAML persistent NameID headings, but they are strongly discouraged.
The precise set of SAML 1.1 attributes supported is:
urn:mace:dir:attribute-def:eduPersonPrincipalName(preferred)urn:oasis:names:tc:SAML:attribute:subject-id(SAML Subject ID, new proposed standard, preferred)urn:oasis:names:tc:SAML:attribute:pairwise-id(SAML Pairwise ID, new proposed standard, discouraged)urn:oid:1.3.6.1.4.1.5923.1.1.1.10(targetedID as SAML attribute, strongly discouraged)urn:mace:dir:attribute-def:displayName(preferred)urn:mace:dir:attribute-def:cnurn:mace:dir:attribute-def:mail
For SAML 2.0:
...
urn:oid:1.3.6.1.4.1.5923.1.1.1.6 (EPPN, preferred)
...
urn:oasis:names:tc:SAML:attribute:subject-id (SAML Subject ID, new proposed standard, preferred)
...
urn:oasis:names:tc:SAML:attribute:pairwise-id (SAML Pairwise ID, new proposed standard, discouraged)
...
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (targetedID as NameID, strongly discouraged)
...
urn:oid:1.3.6.1.4.1.5923.1.1.1.10 (targetedID as SAML attribute, strongly discouraged)
...
urn:oid:2.16.840.1.113730.3.1.241 (displayName, preferred)
...
urn:oid:2.5.4.3 (cn)
...
, as it will redirect to a dashboard that provides direct access to a Jira project set up for each member to raise requests. Access to the support feature is limited to Atlassian accounts identified by one or more access managers identified within each member organization to identify the people with access.