Portal 7.4 protect /IRJ with SAML but leave basic for /NWA

[AaronH]

Greetings!

When following the standard procedure for setting up Single Sign-on for a Netweaver JAVA/Portal 7.4-based system (specifically, SAML 2.x), you normally go into NWA > Configuration > "Authentication and Single Sign-On" and modify the "ticket" policy by adding the Login Module of your choice (in my case, SAML 2.x).

Example documentation:

Configuring the AS Java to Issue Logon Tickets - User Authentication and Single Sign-On - SAP Librar...

Protecting Resources with SAML - User Authentication and Single Sign-On - SAP Library

However, when you do this, you impact nearly all aspects of accessing the Netweaver (JAVA) system, both /irj and /nwa areas now use SSO.  This would normally be a good thing, but if anything goes badly with the Identity Provider, then users unable to login, even with the BasicPasswordLoginModule set as requisite AFTER SAML.  You can reproduce this situation if you set SAML to trust an Identity Provider and then shutdown the identity provider.  Now, when you try to login to the Portal, it will redirect you to where the Identity Provider should be, but since you can't access it (it's shutdown), you are stuck.  Portal doesn't know that it should fail to Basic auth since it doesn't realize the Identity Provider is offline.  The only way around in this situation that I've found is to go into the ConfigTool and disable SAML there, then you can login again with Basic authentication after a restart.

So, the question is, what's the best way to enable SSO (SAML) ONLY for /irj, but leave Basic Auth for /nwa?  That way, if anything happens that screws up SAML, the admins can easily login to /nwa and fix the issue.  Should I continue to edit the 'ticket' or maybe create a new policy and somehow assign Portal (/irj) to the new one and leave ticket alone?  Or, is there a way to for /nwa to always use basic?

I've been looking everywhere for configuring at this detailed level and haven't run into anything yet.

Thanks in advance for any advice,

Aaron

[former_member244149 · Accepted solution]

Hello Aaron,

your post is one year old with no advice.

I've been looking for the same solution quite long time.

Did you find anything helpful?

Slavomir

[AaronH · Accepted solution]

Hi,

We did find a solution.  SAP also created a note detailing a work-around in the scenario I identified.

1874339 - Disabling the SAML2 login module via URL allowing user/password login instead.

Basically, just add to the end of the url the following: ?saml2=disabled

Example, calling /nwa with SAML2 disabled:  http://<hostname>:<port#>/nwa?saml2=disabled

By doing this, the SAML2 login module will be skipped allowing the BasicPasswordLoginModule to be called thus allowing you to log in with a user and password.

This will work for anything else currently using the SAML login module, such as /irj (sap portal).  The added benefit for this is helping with testing/qa purposes so you can test against the full infrastructure in place and just bypass the SSO capability.

I hope this helps.

Aaron

[Dan_Schultz · Accepted solution]

Hi Aaron,

Came across your post this morning as I have an issue using the saml2=disable parameter and /IRJ.  Once SAML2 logon module is bypassed and the basic logon module presents the UserID/Password form, no credentials are accepted.

What other changes did you make (i.e., authentication scheme) to allow you to successfully bypass SAML2 and logon using UserID/Password?

Regards,

Dan

[AaronH · Accepted solution]

Hi Dan,

Your problem is most likely with list and order of login modules you've added to 'ticket'.

Try this order:

EvaluateTicketLoginModule SUFFICIENT
SAML2LoginModule OPTIONAL
CreateTicketLoginModule OPTIONAL
BasicPasswordLoginModule REQUISITE
CreateTicketLoginModule OPTIONAL

[Dan_Schultz · Accepted solution]

Hi Aaron,

Thanks for the suggested order.  My issue is resolved.  I had previously had the login modules in this suggested order during my initial implementation of SAML2 but kept encountering issues with SAML2 which ultimately turned out to be metadata related.  Now it works as expected.

Regards,

Dan