Hi Matt,

we are suing this functionality in NAM 5.0.4 so I'm very interested in this, so please update when you got any news.

Otherwise in my experience often when you end up in user portal it's often related to that authncontextclassref in saml response is not what NAM is expecting

/Lennart

Hi Matt!

I actually don't see this problem.

Using NAM5.1 appliance I can use both /nidp/saml2/idpsend?PID=<PID> and /nidp/saml2/idpsend?id=<id>. In both cases I can see SAML message and user redirected to application.

There is only one fact. My test SP did not have ID value set on "Intersite Transfer Service" tab before upgrade, so I have set it when system was already upgraded to 5.1. I don't know if this makes any difference.

What if you create appmark pointing to SAML SP? It should create URL with PID.

Kind regards,

Sebastijan

I tried using PID= and TARGET=, got the same behavior.

I tried deleting the SP and recreating it, same behavior.

I tried a different ID value, same behavior.

I tried altering various other configuration parameters, nothing I did would cause the IdP to issue a SAML Assertion.

Creating an Appmark worked.  If I go to /nidp/app/portal and pick the Appmark I created, the SAML Assertion is generated.  However, if I try and use the URL the Appmark generated independently, it does not work, I get the same behavior, no assertion generated and the user is left in the nidp portal.

I should point out that SP initiated works fine too.  It's only when I try IdP initiated using an ID or with PID= the entity ID that this doesn't work.

Matt

I will keep this updated. I opened a critical support ticket on August 28th and we are no where.  Support is just so awful right now.  The people answering the tickets are nothing more than messengers passing emails back and forth.  It's a serious problem for this product.  I did finally get someone more senior to take the case after a week, but nothing new, we basically started over because no one understood the problem.

As I advise most folks, avoid 5.1 right now, it's just not worth it and it adds next to no value in most environments.  I only load it in test/dev environments.

Matt

Matt Weisberg said:

Creating an Appmark worked.  If I go to /nidp/app/portal and pick the Appmark I created, the SAML Assertion is generated.  However, if I try and use the URL the Appmark generated independently, it does not work, I get the same behavior, no assertion generated and the user is left in the nidp portal.

Now that is really strange...

All that appmark does is simple http GET with specific URL. And URL for SAML SP can be seen in appmark configuration (section "URL used by Appmark on User Portal (read only).")

I know that it is hard to check what exactly appmark does, since it opens new tab, but if using something like SAML tracer (which records traffic across tabs) or fiddler, can you maybe see difference in call from Appmark and when manually running same URL?

I have also deployed 5.1 only in test/dev environments. But mainly because of problems in admin interface (like loosing all ldap attributes during upgrade, cannot enable session assurance, ...)

The problem is issuing the request prior to the user having logged in.  Even if I take the Appmark generated URL it does the same thing, dumps the user into the portal after the authentication.

I actually just duplicated the problem in another environment, so it is yet another bug in this crappy release.

Anyone can test it, as I've explained to support, just create an SP with some dummy metadata, doesn't have to be real, and set a dummy target and ID on the intersite transfer page.

Then go to:

https://myidp.whatever.com/nidp/saml2/idpsend?id=<myID>

You'll be prompted to authenticate and then be dumped into the IdP portal.

If you do it after you have already authenticated, it works.

Matt

Oh, this is a horrible release.  How about losing all your Advanced File Configurator customizations? Did they even test this?

I think you pointed out the Kerberos issues in another thread.

And what about messing up the IdP URL if you use :443 and make an edit? Seriously?  Granted, there is an easy work around.

The big problem is, a lot of folks are clamoring for the updated tomcat, apache, java, etc. so they can pass "security" scans, but I cannot in good faith tell ANYONE to load this version.

What LDAP attributes get lost during the upgrade?  I wasn't aware of that one!

I've pretty much never been able to use session assurance.

There should be a big warning on the 5.1 download that it is still BETA code as far as I'm concerned or at least a list of the known issues.

Matt

Hi Matt!

All my previous tests were with already authenticated user. But now I have tested also with unauthenticated user and it also works.

I'm just wondering what is difference between yours and mine setup...

I see following URLs called:

GET https://idp.example.com/nidp/saml2/idpsend?id=samlSPid -> initial URL pasted into browser
POST https://idp.example.com/nidp/saml2/idpsend?id=samlSPid -> POST with deviceAttributes (device fingerprinting)
GET https://idp.example.com/nidp/app?target=https%3A%2F%2Fidp.example.com%2Fnidp%2Fsaml2%2Fidpsend%3Fid%3DsamlSPid -> request for authentication with initial target
GET https://idp.example.com/nidp/app?sid=0&option=credential -> URL actual authentication, some additional URLs follow until credentials are POSTed
POST https://idp.example.com/nidp/app/login?sid=0&sid=0&uiDestination=nidpContent -> after POST of credentials again call for device fingerprinting
GET https://idp.example.com/nidp/saml2/idpsend?id=samlSPid -> redirect to target specified in 3rd call
POST https://samlSP.example.com/saml2endpoint -> POST with SAML response to target application

Kind regards,

Sebastijan

Matt Weisberg said:

What LDAP attributes get lost during the upgrade?  I wasn't aware of that one!

List in IDP Global Settings->Custom Attributes->LDAP Attributes was empty after appliance upgrade (from 5.0.4 to 5.1). Not thaqt it was missing my custom attributes, it was completely empty.

As a consequence no attribute set was working.

I needed to create snapshot of current 5.1 version, revert to 5.0.4 snapshot, get list of all LDAP custom attributes, revert back to 5.1 snapshot and add all attributes back to 5.1.

Then all virtual attributes and attribute set were working again.

It was a simple solution, but unneeded.

Kind regards,

Sebastijan