
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hi!
We have IDM federated with NAM using SAML. After upgrade of IDM to 4.8.2.1 last night, users are experiencing errors whenever Identity Application tries to extend user's session (session on IDM has expired).
When IDM is extending session, SAML request is sent with Subject and SPProvidedID, like this:
<samlp:AuthnRequest xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Consent="urn:oasis:names:tc:SAML:2.0:consent:unavailable" Destination="https://nam.server.net/nidp/saml2/sso" ForceAuthn="false" ID="id-e6AkRnHMiYJddujfJQr5dn3WGo" IsPassive="false" IssueInstant="2020-12-15T13:46:24Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" >
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idm.server.net/osp/a/idm/auth/saml2/metadata</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="false" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" SPNameQualifier="https://idm.server.net/osp/a/idm/auth/saml2/metadata" SPProvidedID="uaadmin" >uaadmin</saml:NameID>
</saml:Subject>
</samlp:AuthnRequest>
Response from NAM is simple, RequestDenied:
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://idm.server.net/osp/a/idm/auth/saml2/spassertion_consumer" ID="id3YGeLRMfiTCOB0ukkAdBppo3mYM" InResponseTo="id-e6AkRnHMiYJddujfJQr5dn3WGo" IssueInstant="2020-12-15T13:46:24Z" Version="2.0" >
<saml:Issuer>https://nam.server.net/nidp/saml2/metadata</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
.............
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" />
</samlp:StatusCode>
</samlp:Status>
</samlp:Response>
Looking at catalina, I can see following error:
<amLogEntry> 2020-12-15T13:46:24Z WARNING NIDS Application: AM#300105014: AMDEVICEID#929A1803F1E309DD: AMAUTHID#9393cea69c1ad41a38c48faa8a450012b70454ed91cdb60db7af00df4cce81db: Failed to locate the subject identified in authentication request from https://idm.server.net/osp/a/idm/auth/saml2/metadata </amLogEntry>
Please note:
- There is only one uaadmin user in whole userstore (username in SAML request hint)
- This happens when Identity application tries to reauthenticate, so initial authentication on NAM with uaadmin user was successful
- When reauthentication happens, NAM session is still live, so if I just go to IDMApps URL, user will be automatically authenticated (because in that case SAML request does not hold <saml:Subject> element)
Has anybody else seen something like this?
Kind regards,
Sebastijan

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
It still isn't working for me. The one that that I can tell that is different is the SAML attribute that NAM sends to IDM is idvLoginID instead of cn. It is the cn in NAM, but not the cn in IDM. I have SAML2 NAMEID ATTRIBUTE NAME set to cn and it is the same username value but it seems like NAM still doesn't find the user from the AuthnRequest:
<samlp:AuthnRequest xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unavailable"
Destination="https://nam.domain.com/nidp/saml2/sso"
ForceAuthn="false"
ID="id4gzOrv-taUt7Hou8jzBhgoltUVM"
IsPassive="false"
IssueInstant="2020-12-22T20:37:28Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
>
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://userapp.domain.com/osp/a/idm/auth/saml2/metadata</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="false"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
/>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
SPNameQualifier="https://userapp.domain.com/osp/a/idm/auth/saml2/metadata"
SPProvidedID="username"
>username</saml:NameID>
</saml:Subject>
</samlp:AuthnRequest>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Destination="https://userapp.domain.com/osp/a/idm/auth/saml2/spassertion_consumer"
ID="idHPm1q0uz12yZMA13rnx_iTuP3fE"
InResponseTo="id4gzOrv-taUt7Hou8jzBhgoltUVM"
IssueInstant="2020-12-22T20:37:28Z"
Version="2.0"
>
<saml:Issuer>https://nam.domain.com/nidp/saml2/metadata</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<CanonicalizationMethod xmlns="http://www.w3.org/2000/09/xmldsig#"
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#idHPm1q0uz12yZMA13rnx_iTuP3fE">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">1v9wKwuF2KoiqfKJ3d95Y+T65kkys6WDVhO3GWF5+Nw=</DigestValue>
</ds:Reference>
</ds:SignedInfo>
<SignatureValue xmlns="http://www.w3.org/2000/09/xmldsig#">xxx
</SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>xxx</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" />
</samlp:StatusCode>
</samlp:Status>
</samlp:Response>
A fresh session that works looks like this:
<samlp:AuthnRequest xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
Consent="urn:oasis:names:tc:SAML:2.0:consent:unavailable"
Destination="https://nam.domain.com/nidp/saml2/sso"
ForceAuthn="false"
ID="id52afjaVPZmXFHrqJx-8xkCYjvH0"
IsPassive="false"
IssueInstant="2020-12-22T20:59:53Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
>
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://userapp.domain.com/osp/a/idm/auth/saml2/metadata</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="false"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
/>
</samlp:AuthnRequest>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Destination="https://userapp.domain.com/osp/a/idm/auth/saml2/spassertion_consumer"
ID="id-pWR5MN3nZvJmuNXJkmBUX2SBP4"
InResponseTo="id52afjaVPZmXFHrqJx-8xkCYjvH0"
IssueInstant="2020-12-22T20:59:53Z"
Version="2.0"
>
<saml:Issuer>https://nam.domain.com/nidp/saml2/metadata</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<saml:Assertion ID="idui-G3cKWP4jVH2QbVq954_DLqyA"
IssueInstant="2020-12-22T20:59:53Z"
Version="2.0"
>
<saml:Issuer>https://nam.domain.com/nidp/saml2/metadata</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<CanonicalizationMethod xmlns="http://www.w3.org/2000/09/xmldsig#"
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#idui-G3cKWP4jVH2QbVq954_DLqyA">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">641VNBWC78b/xJ7CqD4YQuwafLrrtP1JV8di2kCvA5s=</DigestValue>
</ds:Reference>
</ds:SignedInfo>
<SignatureValue xmlns="http://www.w3.org/2000/09/xmldsig#">xxx
</SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>xxx
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
NameQualifier="https://nam.domain.com/nidp/saml2/metadata"
SPNameQualifier="https://userapp.domain.com/osp/a/idm/auth/saml2/metadata"
>username</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="id52afjaVPZmXFHrqJx-8xkCYjvH0"
NotOnOrAfter="2020-12-22T21:04:53Z"
Recipient="https://userapp.domain.com/osp/a/idm/auth/saml2/spassertion_consumer"
/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2020-12-22T20:54:53Z"
NotOnOrAfter="2020-12-22T21:04:53Z"
>
<saml:AudienceRestriction>
<saml:Audience>https://userapp.domain.com/osp/a/idm/auth/saml2/metadata</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2020-12-22T19:31:47Z"
SessionIndex="idui-G3cKWP4jVH2QbVq954_DLqyA"
>
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
<saml:AuthnContextDeclRef>http://vermeer.name/password</saml:AuthnContextDeclRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Name="idvLoginID"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
>
<saml:AttributeValue xsi:type="xs:string">username</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Then let's compare NAM versions, if this could be the reason reason. My working environment is using "latest and greatest" 4.5.3 HF1.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
And do you see same error in NAM IDP's catalina.out as I did?
Failed to locate the subject identified in authentication request from

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
I am running NAM 4.5.3 with a bug patch for the oauth attribute format. I get the same error that you have in catalina.out.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
I could only suggest to update to 4.5.3 HF1 (which also fixes oauth attribute format) and then try again. If it still does not work, you'll have to open SR.
- « Previous
-
- 1
- 2
- Next »