May a shibboleth IdP deliver attributes for authZ without preceding authN ?

Markus Ludwig Grandpre markus.grandpre at uni-konstanz.de
Mon Oct 10 13:14:47 BST 2011


Hello list,

currently I'm testing a saml2 module for freeradius. After authN has
succeeded freeradius server is requestind a Shibboleth IdP for some
attribute values of authenticated user.

Therefore the saml module starts to send an AttributeQuery request
(without preceding exchange of AuthN requests and responses) and idp
returns requested attribute values in a AttributeQuery response. But
when saml2 module is about to validate received response it claims that
there is no AuthNStatement within AttributeQuery response (some
configuration details below).

Off course it would be possible to reprogram saml2 module in order to
disable validation of required AuthNStatement and only to parse received
attribute values, but i am afraid this approach would not confirm to
saml standard. What do you think?

Is there a SAML confirm approach to make Shibboleth only to deliver
required attribute values for authZ after authN has taken place
somewhere else?

Best regards, Markus

---------------------------------------------

Required attributes are defined in SP's metadata:

<AttributeConsumingService index="1">
 <ServiceName xml:lang="en">
  Moonshot Radius SP
 </ServiceName>
 <ServiceDescription xml:lang="en">
  Radius SP
 </ServiceDescription>
 <RequestedAttribute
  FriendlyName="surname"
  Name="urn:oid:2.5.4.4"
  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
  isRequired="true"/>
 <RequestedAttribute
  FriendlyName="givenName"
  Name="urn:oid:2.5.4.42"
  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
  isRequired="true"/>
 <RequestedAttribute
  FriendlyName="email" Name="urn:oid:1.2.840.113549.1.9.1.1"
  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
  isRequired="true"/>
 <RequestedAttribute
  FriendlyName="title"
  Name="urn:oid:2.5.4.12"
  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
  isRequired="false"/>
</AttributeConsumingService>

Principal connector in IdP's resolver configuration:

<resolver:PrincipalConnector
 xsi:type="pc:Direct"
 id="saml2persistentId"
 nameIDFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:blahblahblah"
/>

IdP's filter policy for required attributes

<afp:AttributeFilterPolicy id="releaseTransientIdToAnyone">
  <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
  <afp:AttributeRule attributeID="transientId">
   <afp:PermitValueRule xsi:type="basic:ANY"/>
  </afp:AttributeRule>
   <afp:AttributeRule attributeID="surname">
   <afp:PermitValueRule xsi:type="basic:ANY"/>
  </afp:AttributeRule>
   <afp:AttributeRule attributeID="givenName">
   <afp:PermitValueRule xsi:type="basic:ANY"/>
  </afp:AttributeRule>
   <afp:AttributeRule attributeID="email">
   <afp:PermitValueRule xsi:type="basic:ANY"/>
  </afp:AttributeRule>
   <afp:AttributeRule attributeID="title">
   <afp:PermitValueRule xsi:type="basic:ANY"/>
  </afp:AttributeRule>
 </afp:AttributeFilterPolicy>











More information about the users mailing list