Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Anonymous_User Absent Member.
Absent Member.
1067 views

IDP side error with new SP


Hi All,

Setting up a standard SAML 2.0 connection for an SP with NAM 4.2.1.0.29.


When I hit the SP URL and get redirected to the IDP, I see the
AuthnRequest, followed by an error on the IDP side: Warning: Invalid
resource key: Signature encoding error. No prefix!

I've tried a few different nameID settings based on an article I found
(which was very loosely linked to this issue); this didn't do anything.
Any ideas on where I might find more information/log on this error?
Anyone run into this before?

Samples of authnRequest and response below (any identifying details
removed and replaced with <snip>):

Code:
--------------------
************************* SAML2 Redirect message ********************************

Type: received
RelayState: None
<samlp:AuthnRequest AssertionConsumerServiceURL='https://abc.com/api/v1/users/saml' Destination='https://<snip>/nidp/saml2/sso' ID='_49399319-ab07-4b9d-b11c-cf189e7ec80e' IssueInstant='2016-10-12T02:26:53Z' Version='2.0' xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion' xmlns:samlp='urn:oasis:names:tc:SAML:2.0:protocol'><saml:Issuer>https://<snip>/api/v1/users/saml_metadata/2f0f8a64-06a8-41f5-8e58-c39ffe53dbfe</saml:Issuer></samlp:AuthnRequest>
************************* End SAML2 message ****************************

************************* SAML2 POST message ********************************

Type: sent
Sent to: https://<snip>/api/v1/users/saml RelayState: None
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Destination="https://<snip>/api/v1/users/saml" ID="id452ZJ3QW2loI5L07EJsjXR-nVA0" InResponseTo="_49399319-ab07-4b9d-b11c-cf189e7ec80e" IssueInstant="2016-10-12T02:26:54Z" Version="2.0"><saml:Issuer>https://<snip>/nidp/saml2/metadata</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id452ZJ3QW2loI5L07EJsjXR-nVA0">
<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/2000/09/xmldsig#sha1"/>
<ds:DigestValue>09DU6OdJrQGInBI9xiIyIHbopkc=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
<snip>
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
<snip>
</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>
************************* End SAML2 message ****************************
--------------------



Thanks,

Glen.


--
gwickert
------------------------------------------------------------------------
gwickert's Profile: https://forums.netiq.com/member.php?userid=8224
View this thread: https://forums.netiq.com/showthread.php?t=56688

0 Likes
7 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: IDP side error with new SP


gwickert;271742 Wrote:
> Hi All,
>
> Setting up a standard SAML 2.0 connection for an SP with NAM 4.2.1.0.29.
>
>
> When I hit the SP URL and get redirected to the IDP, I see the
> AuthnRequest, followed by an error on the IDP side: Warning: Invalid
> resource key: Signature encoding error. No prefix!
>
> I've tried a few different nameID settings based on an article I found
> (which was very loosely linked to this issue); this didn't do anything.
> Any ideas on where I might find more information/log on this error?
> Anyone run into this before?
>
>


Try recreating the SP under a different name.

Cheers,
Edward


--
edmaa
------------------------------------------------------------------------
edmaa's Profile: https://forums.netiq.com/member.php?userid=1118
View this thread: https://forums.netiq.com/showthread.php?t=56688

0 Likes
Knowledge Partner
Knowledge Partner

Re: IDP side error with new SP

That error sounds familiar.

Is your NAM IDS the IDP or is it the SP?
Assuming your NAM IDS is the IDP and you have "something else" that's the SP, AND if it's the error I'm thinking of, it's usually the SP metadata isn't setup properly.

--Kevin
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: IDP side error with new SP


edmaa;271750 Wrote:
> Try recreating the SP under a different name.
>
> Cheers,
> Edward


Hi Edward,

Re-create didn't do anything. Any other ideas? Want me to provide more
logs?


--
gwickert
------------------------------------------------------------------------
gwickert's Profile: https://forums.netiq.com/member.php?userid=8224
View this thread: https://forums.netiq.com/showthread.php?t=56688

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: IDP side error with new SP


Hi All,

After a fair bit of testing and playing today, still no luck.

I noticed a few things:
1. The SP places their signature in a get variable along with the
signature algorithm. We use the POST binding and placed the signature
into the AuthNRequest XML, but still had no luck.
2. SP uses sha-256 for their hashing digest method. I tried setting the
IDP to use that also for their connection; no luck.
3. We tried not using signing at all; no luck.
4. I have asked the SP to use sha-1 as their signing method (using both
embedded XML and GET variables (not at the same time) to house the
signature).

When we try number four, if it still doesn't work, I'll be pretty much
lost. We have 30+ other SPs which all work nicely, so this is starting
to point to an SP related issue - the metadata looks fine though.

Any other ideas? Any idea if I can get more logging out of the IDP,
particularly at the point where it tries to verify the signature of the
incoming AuthNRequest?

Regards,

Glen.


--
gwickert
------------------------------------------------------------------------
gwickert's Profile: https://forums.netiq.com/member.php?userid=8224
View this thread: https://forums.netiq.com/showthread.php?t=56688

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: IDP side error with new SP


Hi All,

Looks like this -may- have been caused by the SP using sha-256 as it
signature algorithm. When the SP forces themselves to use sha-1, we get
further through the authentication flow. We haven't got it to work 100%
this way, but will work on this today.

My question: does NAM support reading signatures produced with sha-256?


There's a SAML property you can set on each SAML connection to make the
IDP sign its own assertions with sha-256, so I'm thinking NAM -should-
support reading them from SPs too.

Can anyone confirm with an SP of their own? Could a NetIQ rep comment on
the support for SPs signing their AuthNRequests with sha-256?

Any help appreciated.

Glen.


--
gwickert
------------------------------------------------------------------------
gwickert's Profile: https://forums.netiq.com/member.php?userid=8224
View this thread: https://forums.netiq.com/showthread.php?t=56688

0 Likes
Knowledge Partner
Knowledge Partner

Re: IDP side error with new SP

gwickert wrote:

> Looks like this -may- have been caused by the SP using sha-256 as it
> signature algorithm. When the SP forces themselves to use sha-1, we
> get further through the authentication flow. We haven't got it to
> work 100% this way, but will work on this today.
>
> My question: does NAM support reading signatures produced with
> sha-256?
>


Based on this comment, it should work on NAM 4.2 SP2, so you might need
to patch to that

https://www.netiq.com/documentation/access-manager-42/accessmanager422-releasenotes/data/accessmanager422-releasenotes.html

Access Manager uses SHA1 Instead of SHA2 During HTTP Redirect Binding
Request #
Issue: When Access Manager acts as an Identity provider, during an HTTP
Redirect binding request, the requests are signed with SHA1 instead to
SHA2. [Bug 963483]

Fix: The issue is resolved as all requests are signed and validated
with SHA2 now.


I know that it didn't support this previously. I recall whenever we did
a federation with ADFS, we had to get them to downgrade their
signatures to SHA-1 (back in the NAM 4.0/4.1 days)

To do this I believe you need to do at least the followng.

Set: SAML2_SIGN_METHODDIGEST_SHA256 to TRUE on the SP you have
configured in NAM as documented here?
https://www.netiq.com/documentation/access-manager-42/admin/data/b65ogn0.html#bvdbf3e


As it sounds like they are using HTTP-redirect (GET) binding rather
than post you also should go to the Profiles and turn off the POST
option for login there (so as to force GET instead of POST)

I believe should work on 4.2.2. If you need help getting this working
on 4.2.1 then you should open a SR.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
Anonymous_User Absent Member.
Absent Member.

Re: IDP side error with new SP


Hi,

Thanks for the response, apologies for my delay.

I did try setting that property on the SAML connection and it still
would not verify their signature. In the end, I just got the SP to use
SHA-1 to get us around the issue.

We will upgrade NAM soon enough, which as you said, should work.

Regards,

Glen.


--
gwickert
------------------------------------------------------------------------
gwickert's Profile: https://forums.netiq.com/member.php?userid=8224
View this thread: https://forums.netiq.com/showthread.php?t=56688

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.