Third party SSO with a custom login module

Question

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.

Answer 1

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.
+_Julius Bussche wrote:_+
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.  
+_Julius Bussche wrote:_+
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