problems seemingly caused by transientID in O365

[Rob Gorrell]

I am experiencing problems with O365 that some subset of our population can
log in just fine while another subset of our population gets treated like
they are unknown users after successfully authenticating at our IdP. I know
MS uses an ImmutableID to match up users that is based on objectGUID. From
my configuration, I have intended to only release UserId and ImmutableID to
their SP per the documentation. But looking at my logs/traces, I seem to be
releasing 3 attributes in the assertion... the extra one being transientID,
something my configuration normally releases to all SPs, but the sample
code seems to already want to deny this... but the deny rule appears to be
ignored in my setup. What I think is happening is MS is confusing the two
name identifiers being released in each assertion... for those users who
work, its because of the ImmutableID, and those that don't, its because of
the transientID.

My question is, why is the transientID being released? Is it a case of
first match wins in policy processing order instead of most restrictive? If
that is so, I could use a little help on the XML, how can I modify the
transientID release to include multiple basic:NOT conditions (to not
release to Google AND Microsoft)?

Here is the relevant sections (in order) of my attribute-filter.xml

<!-- Release the transient ID to anyone (except Google) -->
<afp:AttributeFilterPolicy id="releaseTransientIdToAnyone">
<afp:PolicyRequirementRule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:AttributeRequesterString" value="
google.com/a/uncg.net" />
</afp:PolicyRequirementRule>
<afp:AttributeRule attributeID="transientId">
<afp:PermitValueRule xsi:type="basic:ANY" />
</afp:AttributeRule>
</afp:AttributeFilterPolicy>

<!-- Attribute Filter Policy for Windows Azure AD -->
<afp:AttributeFilterPolicy id="PolicyForWindowsAzureAD">
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString"
value="urn:federation:MicrosoftOnline"/>
<!-- Release userPrincipalName as Windows Azure AD User ID -->
<afp:AttributeRule attributeID="UserId">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
<!-- Release Immutable ID to Windows Azure AD -->
<afp:AttributeRule attributeID="ImmutableID">
<afp:PermitValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
<!-- Note: it is not recommended to send transientId to Windows
Azure AD -->
<afp:AttributeRule attributeID="transientId">
<afp:DenyValueRule xsi:type="basic:ANY"/>
</afp:AttributeRule>
</afp:AttributeFilterPolicy>

[Paul Hethmon]

My question is, why is the transientID being released? Is it a case of first match wins in policy processing order instead of most restrictive? If that is so, I could use a little help on the XML, how can I modify the transientID release to include multiple basic:NOT conditions (to not release to Google AND Microsoft)?

Rob,


<afp:PolicyRequirementRule xsi:type="basic:AND">

<basic:Rule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://randomsp1.com/" />
</basic:Rule>
<basic:Rule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://randomsp2.com" />
</basic:Rule>
<basic:Rule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://randomsp3.com" />
</basic:Rule>

</afp:PolicyRequirementRule>


cheers,

Paul

Paul Hethmon
Chief Software Architect
paul.hethmon-NC06ibP+gDOju1H+chf1WFaTQe2KTcn/@public.gmane.org

[Aaron Howell]

Or if you want to use less XML, this should be equivalent to what Paul posted.

<afp:PolicyRequirementRule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:OR”>
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://randomsp1.com/" />
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://randomsp1.com/" />
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://randomsp1.com/" />
</basic:Rule>
</afp:PolicyRequirementRule>

Cheers,
Aaron

Post by Paul Hethmon

My question is, why is the transientID being released? Is it a case of first match wins in policy processing order instead of most restrictive? If that is so, I could use a little help on the XML, how can I modify the transientID release to include multiple basic:NOT conditions (to not release to Google AND Microsoft)?

Rob,
<afp:PolicyRequirementRule xsi:type="basic:AND">
<basic:Rule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://randomsp1.com/" />
</basic:Rule>
<basic:Rule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://randomsp2.com" />
</basic:Rule>
<basic:Rule xsi:type="basic:NOT">
<basic:Rule xsi:type="basic:AttributeRequesterString" value="http://randomsp3.com" />
</basic:Rule>
</afp:PolicyRequirementRule>
cheers,
Paul
Paul Hethmon
Chief Software Architect
--

Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.

Deakin University does not warrant that this email and any attachments are error or virus free.

[Cantor, Scott]

Post by Rob Gorrell
My question is, why is the transientID being released? Is it a case of
first match wins in policy processing order instead of most restrictive?
If that is so, I could use a little help on the XML, how can I modify the
transientID release to include multiple
basic:NOT conditions (to not release to Google AND Microsoft)?

Save yourself the hassle. Don't use the filter to control NameID format,
use a precedence setting in relying-party.xml or just specify the format
in the SP's metadata.

We fixed this years ago now precisely because it's so awkward to do this
in the filter.

-- Scott

[Rob Gorrell]

Post by Cantor, Scott
Save yourself the hassle. Don't use the filter to control NameID format,
use a precedence setting in relying-party.xml or just specify the format
in the SP's metadata.

Can you elaborate a little more on the precedence setting in relying-party?
In this particular case, the SP is Microsoft's O365 where they don't
provide us any control over setting the NameID format in their metadata, so
I'm not sure that is an available option with this particular SP.

-Rob

[Cantor, Scott]

Post by Rob Gorrell
Can you elaborate a little more on the precedence setting in
relying-party? In this particular case, the SP is Microsoft's O365 where
they don't provide us any control over setting the NameID format in their
metadata, so I'm not sure that is an available option with this
particular SP.

https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty

nameIDFormatPrecedence


-- Scott

[Rob Gorrell]

gotcha, i'm learning something here. so since I'm after releasing a custom
nameid to this SP, it would look like:

<rp:RelyingParty id="urn:federation:MicrosoftOnline" provider="
https://prdidp.uncg.edu/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential"
nameIDFormatPrecedence="ImmutableID">

correct? or is that not the right syntax to reference "custom" nameid's?
my resolver definition for the nameid I'd like to use looks like the
following:

<!-- Use AD objectGUID as ImmutableID for Windows Azure AD -->
<resolver:AttributeDefinition id="ImmutableID" xsi:type="Simple"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
sourceAttributeID="sourceObjectGuid">
<resolver:Dependency ref="myAD" />
<resolver:AttributeEncoder xsi:type="SAML2StringNameID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"

nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
</resolver:AttributeDefinition>

Post by Cantor, Scott

Post by Rob Gorrell
Can you elaborate a little more on the precedence setting in
relying-party? In this particular case, the SP is Microsoft's O365 where
they don't provide us any control over setting the NameID format in their
metadata, so I'm not sure that is an available option with this
particular SP.

https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty
nameIDFormatPrecedence
-- Scott
--
To unsubscribe from this list send an email to

[Cantor, Scott]

Post by Rob Gorrell
gotcha, i'm learning something here. so since I'm after releasing a
<rp:RelyingParty id="urn:federation:MicrosoftOnline"
provider="https://prdidp.uncg.edu/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential"
nameIDFormatPrecedence="ImmutableID">

No. You specify the SAML format you want, has nothing to do with the
underlying attribute. You need something able to encode to the format you
choose.

-- Scott

[Rob Gorrell]

So you are talking about something like:
nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
But what if I have two nameid's encoded as persistent (like ImmutableID and
eduPersonTargetedID") and my filter releases them both, which one wins? Or
is that something i must control with the filter, making sure i'm not
releasing two nameid's of same encoded format?

-Rob

Post by Cantor, Scott

Post by Rob Gorrell
gotcha, i'm learning something here. so since I'm after releasing a
<rp:RelyingParty id="urn:federation:MicrosoftOnline"
provider="https://prdidp.uncg.edu/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential"
nameIDFormatPrecedence="ImmutableID">

No. You specify the SAML format you want, has nothing to do with the
underlying attribute. You need something able to encode to the format you
choose.
-- Scott
--
To unsubscribe from this list send an email to

[Cantor, Scott]

Post by Rob Gorrell
nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persiste
nt"
But what if I have two nameid's encoded as persistent (like ImmutableID
and eduPersonTargetedID") and my filter releases them both, which one
wins? Or is that something i must control with the filter, making sure
i'm not releasing two nameid's of same encoded format?

Yes, that would be a filter issue. That's a very unusual case, and I would
have to conclude that at least one of them is probably not really a SAML
persistent NameID, since such an identifier is purely opaque and the SP
can't be allowed to care what's in it. So if it does, that's not the right
format and the SP is broken.

-- Scott

[Aaron Howell]

"the SP is broken.”

The correct Microsoft term for broken is “By Design"

Post by Cantor, Scott

Post by Rob Gorrell
nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persiste
nt"
But what if I have two nameid's encoded as persistent (like ImmutableID
and eduPersonTargetedID") and my filter releases them both, which one
wins? Or is that something i must control with the filter, making sure
i'm not releasing two nameid's of same encoded format?

Yes, that would be a filter issue. That's a very unusual case, and I would
have to conclude that at least one of them is probably not really a SAML
persistent NameID, since such an identifier is purely opaque and the SP
can't be allowed to care what's in it. So if it does, that's not the right
format and the SP is broken.
-- Scott
--

Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.

Deakin University does not warrant that this email and any attachments are error or virus free.