Third party SSO with a custom login module

[Former Member]

Hello everyone,

I've found a few posts on the forum with questions similar to mine, but none have been answered. I'm using a 3rd party authentication product along with a custom implementation of the AbstractLoginModule interface.

The setup is standard: A 3rd party agent is installed on a reverse proxy web server to SAP. The agent is configured to protect SAP resources, and it handles the login screens and authentication. Once the user has been authenticated, the AbstractLoginModule implementation kicks in, decrypts and validates an SSO token, retrieves the username from it and creates an SAP Principal.

The login ticket template is configured as follows:

1.  EvaluateTicketLoginModule   SUFFICIENT 
                    2.  MyLoginModule                      REQUISITE 
                    3.  CreateTicketLoginModule       OPTIONAL

-

---

One of the integration's key requirements is that direct interaction with standard SAP authentication must be avoided. More specifically, the user should never need to enter an SAP password. I'm only seeing two problems, both of which violate this requirement.

The first is in cases where there is no existing SAP user that matches the authenticated user. In this case, the third party token and SAP Principal are created, the abort method is called, and the user is redirected to the SAP login page. I need to either bring to user back to the third party login page or to a custom error page~.

The second problem occurs when an SAP password change is required. Again in this case, an SAP form is displayed after the module has created the Principal (although once the user changes the SAP password, all's well). If I were to disable mandatory password changes, would this apply to fat client access as well? If so, then it's not a viable option.

The general idea in both instances is that the SAP I'd appreciate any help or suggestions.

Thanks

~ Since the SSO token applies to applications outside of SAP, I may add a login module parameter to make this a configurable choice. (I.e. allow the administrator to decide whether to inform the user that SAP authentication failed while preserving the SSO token, or to destroy the token and force re-authentication). However, if there is a way to configure the "bad credentials" URL outside of the module's code/parameters, it may be better to place the choice there.

[Former Member]

I would say it is a better option that your custom login module does an existence check and reacts to it.

For the first concern, if they can access the logon page directly (anyway) you could disable it as you do not want any password based logons (right?) and redirect it to your external page or an error page. Or use a forward proxy to only present the page to admins in the server network.

For the second concern, I assume that there are no valid passwords involved here which might have expired, so as long as the user does not have the option to activate a password again and anyway cannot logon via password as the option is not presented... then you should be fine here as well with a forward proxy. Not sure which Java APIs are offered here, but you could check this together with the existence check and react to both prior to accessing SAP "from the outside".

Perhaps if you explain your setup more then we can play around with the options. It might also well be that there is a Java backend config option with APIs for external callers - on the ABAP stack there are.

Cheers,

Julius

[Former Member]

Hi Julius,

Thank you for the quick response - and on a Sunday, no less!

I have considered verifying that the user existed in SAP before creating the Principal. One might argue that that would be the common sense thing to do. The reason I've held off is that the error should be so rare that it may not justify the overhead. There's a requirement to have a one-to-one username mapping between SAP and the authentication application. It would be more efficient to assume that this requirement has been met and to handle the Exception when it hasn't been. Of course, that doesn't mean that it's the right way to go.

 For the first concern, if they can access the logon page directly (anyway) you could disable it as you do not want any password based logons (right?) and redirect it to your external page or an error page.

Yes, this is what I'm hoping to do, but I'm not sure how to do it. Here are some comments and questions about this:

1. What's involved in disabling the login page? I would think you'd need to replace it with something else rather than just switch it off. Could I limit this change to the login ticket template so that other templates (basic authentication, for example) are still available?

2. Keep in mind that users will never get past the "real" login page unless they have been authenticated. This complicates matters because we're dealing with a scenario in which the user has already been authenticated but doesn't exist in SAP. Therefore, it wouldn't make sense to go back to either login page.

3. What's involved in redirecting to an external page? Is this an explicit redirect in the module code, or can it be decoupled from the module? It's not a big deal, but it would be nice to avoid mandatory module parameters for relative paths to error pages.

I think the question I'm after is: "Can I simply change an SAP login URL parameter to point to a custom error page, and allow everything to work as it does now (where SAP handles the redirect)". If so, could I limit the scope of the change to the login ticket template? What would be even better is if I could configure SAP's response to this error. Somewhere, it's currently configured to display the login page. Ideally, I'd be able to configure it to display myErrorPage, and then set myErrorPage to the appropriate URL.

 For the second concern, I assume that there are no valid passwords involved here which might have expired, so as long as the user does not have the option to activate a password again and anyway cannot logon via password as the option is not presented... then you should be fine here as well with a forward proxy. Not sure which Java APIs are offered here, but you could check this together with the existence check and react to both prior to accessing SAP "from the outside".

The problem here is that the SAP passwords are needed outside of the integration. It's true that whether an SAP password has expired is irrelevant to the integration. However, this is a Web-based integration; SAP passwords must still be available to users who have access to other clients. With this in mind, could I create a user password policy that disables password expiration and automatic password change, but only apply it to Web client access? If not, do you know how I might override SAPu2019s behavior?

Once again, thank you for taking your time to help me out. I am very grateful.

- John

[Former Member]

The problem here is that the SAP passwords are needed outside of the integration. It's true that whether an SAP password has expired is irrelevant to the integration. However, this is a Web-based integration; SAP passwords must still be available to users who have access to other clients. With this in mind, could I create a user password policy that disables password expiration and automatic password change, but only apply it to Web client access? If not, do you know how I might override SAPu2019s behavior?

For this Point I would advise all the web users to be created as service users without impacting your password policy.

[Former Member]

Hello again Julius,

Do you have any insights into my follow-up questions? I'm stuck on the implementation details and unclear on potential repercussions I may face. Can you give me some direction when you get a chance. Thanks for your help.

[Former Member]

Hi Venkatesh,

Thanks for your reply. Can you tell me what the implications would be in terms of user administration? If it means that two sets of users would need to be maintained in parallel, it really isn't a feasible solution as there are tens of thousands of users. Each set of users would need identical profiles with the exception of the password policy.

Can you think of any other way to solve the problem? For example, is there a way to assign a policy based on the client application rather than the user (that would be the best choice if available).

Thanks again.

[Former Member]

Can I assume that you have a webdispatcher between the 3rd party clients and your server? Can I assume it is in a DMZ and there is no accessible redundancy?

In this case, your admins are "on the inside" or can VPN into it to access the logon screen if need be.

Which protocoll don't you like about network topology?

Cheers,

Julius

[Former Member]

Hi Julius,

Your assumptions are correct, but the goal here is to keep everyone (including admin users) away from the standard web login screen. The integration has it's own login screen, and the integrated security app manages passwords and password policies.

The problem is that most users (not just admin) can access NetWeaver through other clients. I can disable automatic password change in the SAP security policy to avoid the problem, but that would pose another problem, because the same policy would apply to non-web access.