Unexpected reproducible behavior of PermitValue rule of type ScopeRegex in Shibboleth SP 3.4.1
Florian Lengyel
Florian.Lengyel at cuny.edu
Tue Jan 2 02:41:05 UTC 2024
Two typos fixed (the version number should have been 3.4.1, and the more restrictive regex began with `^.*`--this is fixed below.
All of the behavior is as described and reproducible. I apologize for the previous email. -F
From: users <users-bounces at shibboleth.net> On Behalf Of Florian Lengyel via users
Sent: Monday, January 1, 2024 9:32 PM
To: users at shibboleth.net
Cc: Florian Lengyel <Florian.Lengyel at cuny.edu>
Subject: Unexpected reproducible behavior of PermitValue rule of type ScopeRegex in Shibboleth SP 3.4.1
* This email originates from a sender outside of CUNY. Verify the sender before replying or clicking on links and attachments. *
Hi,
I've installed Shibboleth SP 3.4.1 by RPM on two Red Hat 7.9 Linux systems.
Their purpose is to test Token Issuance Policies in Oracle Access Manager (OAM) 12.c.
Here OAM functions as the IdP. The service provider is not a production system.
The SP has a relatively trivial `shibboleth-policy.xml`. A minor change to the regex of an
AttributeRule of type `ScopeRegex` for `eppn` will lead the SP to skip an `eppn` value
that matches a more restrictive regex. This is reproducible behavior.
[I have made some one-for-one substitutions in the output to discourage spamming.
For example, "CUNY" became "PUNY" for "Public University of New York."]
Here is the complete `shibboleth-policy.xml` with the more permissive regex that fails:
<AttributeFilterPolicy id="AllowEppnOnly">
<PolicyRequirementRule xsi:type="basic:ANY"/>
<AttributeRule attributeID="eppn">
<PermitValueRule xsi:type="ScopeRegex" regex="^.*\.edu$" />
</AttributeRule>
</AttributeFilterPolicy>
<AttributeFilterPolicy id="AllowAll">
<PolicyRequirementRule xsi:type="basic:ANY"/>
<AttributeRule attributeID="*">
<PermitValueRule xsi:type="basic:ANY"/>
</AttributeRule>
</AttributeFilterPolicy>
The rule itself is permissive-this is for a test system. Also, the unexpected behavior documented below
led me to relax the attribute policy-the purpose was to run performance tests of an IdP.
The log file `/var/log/shibboleth/shibd.log` shows
2024-01-01 20:36:00 WARN Shibboleth.AttributeFilter [2] [default]: removed value at position (0) of attribute (eppn) from (https://idp.puny.edu/oam/fed<https://ssoyellow.cuny.edu/oam/fed>)
2024-01-01 20:36:00 WARN Shibboleth.AttributeFilter [2] [default]: no values left, removing attribute (eppn) from (https://idp.puny.edu/oam/fed<https://ssoyellow.cuny.edu/oam/fed>)
The `eppn` value is in the SAML response, but not in the SP environment. The attribute-map.xml file has the mapping
<Attribute nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
id="eppn">
<AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/>
</Attribute>
SAML response:
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://idp.puny.edu/oam/fed"<https://urldefense.com/v3/__https://idp.puny.edu/oam/fed*22__;JQ!!PxiZbSOawA!P29s7Qe2XCONalok-NfccoUYBYkekIYO6xC1aBRM6BOk4TmHr7fewaV6NkfQ788WndJoOVQlTn9CEKTHM1zeeA83$>
SPNameQualifier="https://fedsso.puny.edu/sp/shibboleth"<https://urldefense.com/v3/__https://fedsso.puny.edu/sp/shibboleth*22__;JQ!!PxiZbSOawA!P29s7Qe2XCONalok-NfccoUYBYkekIYO6xC1aBRM6BOk4TmHr7fewaV6NkfQ788WndJoOVQlTn9CEKTHM5CjInXp$>
>49865801</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="_71f4fc027c7bbe6e6661b0800ebb0e8b"
NotOnOrAfter="2024-01-02T01:41:00Z"
Recipient="https://fedsso.puny.edu/Shibboleth.sso/SAML2/POST"<https://urldefense.com/v3/__https://fedsso.puny.edu/Shibboleth.sso/SAML2/POST*22__;JQ!!PxiZbSOawA!P29s7Qe2XCONalok-NfccoUYBYkekIYO6xC1aBRM6BOk4TmHr7fewaV6NkfQ788WndJoOVQlTn9CEKTHM1PyC8lt$>
/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2024-01-02T01:36:00Z"
NotOnOrAfter="2024-01-02T01:41:00Z"
>
<saml:AudienceRestriction>
<saml:Audience>https://fedsso.puny.edu/sp/shibboleth</saml:Audience<https://fedsso.puny.edu/sp/shibboleth%3c/saml:Audience>>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2024-01-02T01:36:00Z"
SessionIndex="id-EmSaXYobUIwbl1canasS78gkkL0aGK2mQTD2N7MB"
SessionNotOnOrAfter="2024-01-02T02:36:00Z"
>
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.1"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>
<saml:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:type="xsd:string"
>49865801</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="urn:oid:2.16.840.1.113730.3.1.241"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>
<saml:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:type="xsd:string"
>Florian Lengyel</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>
<saml:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:type="xsd:string"
>FLORIAN.LENGYEL94 at login.puny.edu</saml:AttributeValue<mailto:FLORIAN.LENGYEL94 at login.puny.edu%3c/saml:AttributeValue>>
</saml:Attribute>
<saml:Attribute Name="urn:oid:2.5.4.42"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>
<saml:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:type="xsd:string"
>Florian</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="urn:oid:2.5.4.4"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
>
<saml:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsi:type="xsd:string"
>Lengyel</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
The eppn value does not appear in the Session:
Miscellaneous
Session Expiration (barring inactivity): 40 minute(s)
Client Address: 172.27.9.84
SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Identity Provider: https://idp.puny.edu/oam/fed<https://ssoyellow.cuny.edu/oam/fed>
Authentication Time: 2024-01-02T01:36:00Z
Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Authentication Context Decl: (none)
Attributes
displayName: Florian Lengyel
givenName: Florian
persistent-id: 49865801
sn: Lengyel
uid: 49865801
Now let's send the same SAML attribute statement (the SAML response is identical, up to ID, etc.,)
after replacing the regex in the` AllowEppnOnly` AttributeRule above in `attribute-policy.xml` with a more
restrictive regex, as in
<AttributeFilterPolicy id="AllowEppnOnly">
<PolicyRequirementRule xsi:type="basic:ANY"/>
<AttributeRule attributeID="eppn">
<PermitValueRule xsi:type="ScopeRegex" regex="^.*login\.puny\.edu$" />
</AttributeRule>
</AttributeFilterPolicy>
We restart the server, log in as before but this time, the `eppn` value is present!
Now the eppn value is present in the environment-here is a portion of the environment.
Shib_Session_Inactivity: 1704165205
Shib_Session_Index: id-EmSaXYobUIwbl1canasS78gkkL0aGK2mQTD2N7MB
UNIQUE_ID: ZZNxRfz9D8uZRIUA5dRm9wAAAAA
displayName: Florian Lengyel
eppn: FLORIAN.LENGYEL94 at login.puny.edu<mailto:FLORIAN.LENGYEL94 at login.cuny.edu>
givenName: Florian
persistent_id: 49865801
sn: Lengyel
uid: 49865801
The `/var/log/shibboleth/shibd.log` does not show any attributes that were skipped.
tc/shibboleth/sp-encrypt-cert.pem)
2024-01-01 21:12:21 INFO Shibboleth.Listener : listener service starting
2024-01-01 21:12:44 INFO Shibboleth.SessionCache [2] [default]: new session created: ID (_81541e7f04de639945ceaf5848c5d739) IdP (https://ssoyellow.cuny.edu/oam/fed) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (172.27.9.84)
The `Shibboleth.sso/Session` endpoint shows the same mapped attributes.
Miscellaneous
Session Expiration (barring inactivity): 57 minute(s)
Client Address: 172.27.9.84
SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Identity Provider: https://idp.puny.edu/oam/fed<https://ssoyellow.cuny.edu/oam/fed>
Authentication Time: 2024-01-02T01:36:00Z
Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Authentication Context Decl: (none)
Attributes
displayName: Florian Lengyel
eppn: FLORIAN.LENGYEL94 at login.puny.edu<mailto:FLORIAN.LENGYEL94 at login.cuny.edu>
givenName: Florian
persistent-id: 49865801
sn: Lengyel
uid: 49865801
All that changed was the regex from a more permissive to a less permissive pattern.
I have reproduced this on two different systems, with the same software.
This was how I spent the New Year holiday-it does not compute.
Florian
[cid:image004.png at 01DA3CFB.3765B080]
Florian Lengyel, PhD
Identity and Access Management
CUNY CIS 395 Hudson Street, New York, NY 10014
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20240102/e0188c43/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 92 bytes
Desc: image003.gif
URL: <http://shibboleth.net/pipermail/users/attachments/20240102/e0188c43/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 3894 bytes
Desc: image004.png
URL: <http://shibboleth.net/pipermail/users/attachments/20240102/e0188c43/attachment.png>
More information about the users
mailing list