[java-idp-oidc] branch main updated: Comment cleanup.
Scott Cantor
cantor.2 at osu.edu
Tue Jan 19 20:44:37 UTC 2021
This is an automated email from the git hooks/post-receive script.
scantor pushed a commit to branch main
in repository java-idp-oidc.
View the commit online:
http://git.shibboleth.net/view/?p=java-idp-oidc.git;a=commit;h=2098f7e9e25b095e08df39f66993fb9cf5ace955
The following commit(s) were added to refs/heads/main by this push:
new 2098f7e9 Comment cleanup.
2098f7e9 is described below
commit 2098f7e9e25b095e08df39f66993fb9cf5ace955
Author: Scott Cantor <cantor.2 at osu.edu>
AuthorDate: Tue Jan 19 15:44:35 2021 -0500
Comment cleanup.
---
.../oidc/op/conf/oidc-attribute-resolver.xml | 62 ++++++++++++++--------
1 file changed, 40 insertions(+), 22 deletions(-)
diff --git a/idp-oidc-extension-impl/src/main/resources/net/shibboleth/idp/plugin/oidc/op/conf/oidc-attribute-resolver.xml b/idp-oidc-extension-impl/src/main/resources/net/shibboleth/idp/plugin/oidc/op/conf/oidc-attribute-resolver.xml
index 4d9f3c64..c4a03212 100644
--- a/idp-oidc-extension-impl/src/main/resources/net/shibboleth/idp/plugin/oidc/op/conf/oidc-attribute-resolver.xml
+++ b/idp-oidc-extension-impl/src/main/resources/net/shibboleth/idp/plugin/oidc/op/conf/oidc-attribute-resolver.xml
@@ -5,13 +5,20 @@
org.geant.idpextension.oidc.attribute.encoder classpath:/schema/idp-oidc-extension-attribute-encoder.xsd">
<!--
- Exactly one attribute needs to supply the "sub" claim, but this is impossible to fully standardize.
- There are suggested approaches below. Using the scoped encoder is recommended to ensure uniqueness.
+ Some of the examples assume conf/attributes/oidc-claim-rules.xml is loaded
+ into the registry service.
+ -->
+
+ <!--
+ Exactly one attribute needs to supply the "sub" claim, but this can't be
+ fully standardized. There are suggested approaches below. Using the scoped
+ encoder is recommended to ensure uniqueness.
-->
<!--
- This example (the data connector in particular) will generate public or pairwise values depending on client registration.
- The public values will depend on, but not expose, an underlying managed value.
+ This example (the data connector in particular) will generate public or
+ pairwise values depending on client registration. The public values will
+ depend on, but not expose, an underlying managed value.
-->
<AttributeDefinition id="subject" xsi:type="Scoped" scope="%{idp.scope}"
activationConditionRef="shibboleth.oidc.Conditions.SubjectRequired">
@@ -20,7 +27,8 @@
</AttributeDefinition>
<!--
- These examples use activation conditions and filter rules elsewhere to allow for different formats for public and pairwise.
+ These examples use activation conditions and filter rules elsewhere to allow
+ for different formats for public and pairwise behavior.
-->
<!--
<AttributeDefinition id="subject-public" xsi:type="Scoped" scope="%{idp.scope}"
@@ -36,18 +44,22 @@
</AttributeDefinition>
-->
- <!-- The EPPN is the "standard" federated username in higher ed. For guidelines on the implementation of this attribute,
- refer to the Shibboleth and eduPerson documentation. Above all, do not expose a value for this attribute without considering
- the long term implications. This demonstrates use of OIDCScopedString encoder. -->
+ <!--
+ The EPPN is the most common federated username in higher education.
+ For guidelines on the implementation of this attribute, refer to eduPerson
+ and/or federation documentation. Above all, do not expose a value for this
+ attribute without considering the long term implications.
+ -->
<AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" scope="%{idp.scope}">
<InputAttributeDefinition ref="uid" />
<AttributeEncoder xsi:type="oidcext:OIDCScopedString" name="eppn" />
</AttributeDefinition>
<!--
- The uid is the closest thing to a "standard" LDAP attribute representing a local username,
- but you should generally *never* expose uid to federated services, as it is rarely globally unique.
- The default mapping for OIDC is to preferred_username, which seems suitably meaningless.
+ The uid is the closest thing to a "standard" LDAP attribute representing
+ a local username, but you should generally *never* expose uid to federated
+ services, as it is rarely globally unique. The default mapping for OIDC is
+ to preferred_username, which seems suitably meaningless.
-->
<AttributeDefinition id="uid" xsi:type="PrincipalName" />
@@ -59,30 +71,36 @@
]]></Template>
</AttributeDefinition>
- <!-- Start of static attributes. In actual deployment you would use something else than static attributes for most of
- these attributes/claims -->
+ <!--
+ Start of static attributes. In actual deployment you would use a real source
+ for most of these attributes/claims.
+ -->
<AttributeDefinition id="eduPersonScopedAffiliation" xsi:type="Scoped" scope="%{idp.scope}">
<InputDataConnector ref="staticAttributes" attributeNames="affiliation" />
</AttributeDefinition>
<!--
- This demonstrates a complex claim constructed by forming a JSON String.
- The default transcoding rule for the address claim expects the object.
+ This demonstrates a complex claim constructed by forming a JSON structure.
+ The default transcoding rule for the address claim expects such a structure.
-->
<AttributeDefinition id="address" xsi:type="ScriptedAttribute">
<InputDataConnector ref="staticAttributes" attributeNames="street_address locality region postal_code country"/>
- <Script><![CDATA[address.addValue("{\"street_address\":\""+street_address.getValues().get(0) + "\","
+ <Script>
+ <![CDATA[
+ address.addValue("{\"street_address\":\""+street_address.getValues().get(0) + "\","
+"\"locality\":\""+locality.getValues().get(0) + "\","
+"\"region\":\""+region.getValues().get(0) + "\","
+"\"postal_code\":\""+postal_code.getValues().get(0) + "\","
- +"\"country\":\""+country.getValues().get(0) + "\"}");]]></Script>
+ +"\"country\":\""+country.getValues().get(0) + "\"}");
+ ]]>
+ </Script>
</AttributeDefinition>
-
<!--
- Data Connector for generating 'sub' claim. It may be used to generate both public
- and pairwise subject values because it recognizes the OIDC sector_id if used.
+ Data Connector for generating 'sub' claim. It may be used to generate both
+ public and pairwise subject values because it recognizes the OIDC sector_id
+ if used during client registration.
-->
<DataConnector id="computedSubjectId" xsi:type="ComputedId"
generatedAttributeID="subjectId"
@@ -94,9 +112,8 @@
<!--
Static example to populate default claims. Most of these are directly exposed and
- handled by the default set of transcoding rules supplied by the plugin.
+ handled by the default set of transcoding rules provided for optional inclusion.
-->
-
<DataConnector id="staticAttributes" xsi:type="Static"
exportAttributes="telephoneNumber phone_number_verified email_verified displayName sn givenName middle_name eduPersonNickname profile picture website gender birthdate zoneinfo preferredLanguage updated_at">
<Attribute id="affiliation">
@@ -167,4 +184,5 @@
<Value>US</Value>
</Attribute>
</DataConnector>
+
</AttributeResolver>
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
More information about the commits
mailing list