Conditioned attribute

[Jan Marek]

Hello Rod,

many thanks for your e-mail. My notices in the text bellow...

Dne Po, čec 08, 2024 at 12:13:58 CEST napsal(a) Rod Widdowson:
> > I can see that myLDAP produce these attributes
> 
> So, you see a log from net.shibboleth.idp.attribute.resolver.impl.Attribubute Resolver
> 
> 	"Data connector <id>  resolved the following attributes: ..... "
> 
> And that includes "uid" and "displayName"?

Attribute Resolver 'ShibbolethAttributeResolver': Data connector 'myLDAP' resolved the following attributes: [sambaPwdMustChange, sambaPwdLastSet, mail, eduPersonAffiliation, displayName, eduPersonOrgDN, uid, eduPersonPrimaryAffiliation, pager, eduPersonScopedAffiliation, eduPersonTargetedID, sn, entryDN, loginShell, homeDirectory, sambaSID, ou, givenName, mailLocalAddress, objectClass, cn, sambaPrimaryGroupSID, sambaHomeDrive, sambaAcctFlags, eduPersonOrgUnitDN, gecos, eduPersonPrimaryOrgUnitDN, uidNumber, gidNumber]

As you can see, there is a so many attributes, which myLDAP
resolve, but not everythink I would like to use for Shibboleth...

And here are lines before filter:

Final resolved attribute collection: [commonNameASCII, o, samlPairwiseID, authMail, eduPersonTargetedID, eduPersonPrimaryAffiliation, eduPersonScopedAffiliation, sn, samlSubjectID, cn, unstructuredName, mailTCS, uidNumber, roomNumber, eduPersonPrimaryOrgUnitDN, eduPersonOrgUnitDN, givenName, schacHomeOrg, eduPersonUniqueId, eduPersonPrincipalName, eduPersonEntitlement, schacHomeOrgType, eduPersonAffiliation, ou, pager]

Beginning process of filtering the following 25 attributes: [commonNameASCII, o, samlPairwiseID, authMail, eduPersonTargetedID, eduPersonPrimaryAffiliation, eduPersonScopedAffiliation, sn, samlSubjectID, cn, unstructuredName, mailTCS, uidNumber, roomNumber, eduPersonPrimaryOrgUnitDN, eduPersonOrgUnitDN, givenName, schacHomeOrg, eduPersonUniqueId, eduPersonPrincipalName, eduPersonEntitlement, schacHomeOrgType, eduPersonAffiliation, ou, pager]

Between the first line and these last two lines there is not
another line, which mentioned "displayName". "uid" is mentioned,
because it is using for computing some other attributes in Scripted
or Scoped definitions, but, as you can see, to the filter didn't
went.

> 
> That code is so mainline if you are seeing that log message but not the attributes during filtering then something strange is happening.
> 
> But this
> 
> 	<AttributeDefinition xsi:type="Simple" id="pager" preRequested="true">
> 		    <InputDataConnector ref="myLDAP" attributeNames="pager"/>
> 	</AttributeDefinition>
> 
> Feels weird to me.  Attribute names are in a flat name space, what you are doing is defining the an attribute with the same name as the thing that the data connector used.  That makes my head hurt and actually I am surprised that the resolver didn’t detect a circularity.  It would probably be a simplification if you separate the name of the preRequested Attribute from the data-connector product attribute.  I have no idea if this is your problem but it will make life easier for others reading your configuration.
> 

If I understood correctly, attribute "preRequested" is new in 5.x
version of IdP, isn't it? But my version is still 4.x.

But for the 5.x version: Is it correct, when I will have two LDAP
definition, for example, "LDAPForPager" with preRequested attribute
defined and another one, "myLDAP" without this attribute?

> Rod

Sincerely
Jan Marek
-- 
Ing. Jan Marek
University of South Bohemia
Academic Computer Centre
Phone: +420389032080
http://www.gnu.org/philosophy/no-word-attachments.cs.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20240708/e49c1a79/attachment.sig>