Skip to Content

13 Comments

You must be Logged on to comment or reply to a post.

  1. Matthias Braeuer

    Hi Ralf

    Thanks for this post, very interesting, in particular the part about the web deployment config parameter that eliminates the session when switching to another application.

    I’ve got a related question on that: is it possible to destroy a WCEM session “remotely” from another NW AS Java or destroy it when switching to another (non-WCEM) web application?

    In our scenario, we are using SSO tickets issued by WCEM to facilitate the login to another Java web application on another AS Java. To this end, we added a link to this other application to the WCEM user interface. Now, it would be good if a logoff from the other application could delete the WCEM session as well. Curently, a logoff from the other application will remove the SSO cookie but the WCEM session is still intact so navigating back to WCEM will not cause the user to log in again (which is irritating, because the user thinks he has already “logged off”). Basically, we would like to achieve not only Single Sign-On, but also “Single Log-Off”.

    I was thinking that maybe it would be possible to use a similar approach to what you have presented in your article, namely to have the WCEM session killed as soon as we leave the web shop via the link to the external app. As long as the SSO cookie is still present, we should be able to return and continue where we left off, right?

    Thanks for any pointers and best regards,

    Matt

    (0) 
    1. Former Member Post author

      Hi Matt.

      Simply to fullfil the user experience I would tend to remove the session cookie too (JSESSIONID). Now the user would also be logged off from WCEM. Disadvantage, session would still exist on the server, but with a short session timeout period, this shouldn’t be an issue.

      Kind regards,

        Ralf

      (0) 
  2. Former Member

    Hi Ralf,

    Great job, Thanks for this post. I have got a question on that, too. Is it also possible to forward to a specific WCEM application after the central user login?

    In our scenario we will specify the information in the backend about the WCEM applications which are relevant for the user. The corresponding function modules returns the wec-appid and the wec-locale. However, in our most cases only one WCEM application fits for the user. Therefore it would be fine if the central login directly redirects to the relevant WCEM application instead of the application list. Which extension steps are necessary in this case?

    Thanks and

    best regards,

    Daniel

    (0) 
    1. Former Member Post author

      Hello Daniel.
      Thanks for your feedback. I added this use case to the initial post. You will find it at the end of chapter dealing with the ‘applicationList’.

      Kind regards,
        Ralf

      (0) 
      1. Former Member

        Hi Ralf,

        Thanks for the update. We have implement the selection of the correct WCEM application defining own backend objects, business objects and the required module access objects.

        However, a new implementation of a login view is not easy. For that I try to reuse the existing userLoginDetailsView view component. I simply try to extend the method login in the responsible UserLoginVCHandler to redirect to the view showing the application list as described. Unfortunately, the user module has only an ‘internal’ public part which contains the responsible handler UserLoginVCHandler. We are not allowed to use them. Why sap has this restriction? Is there an easy way to extend the existing login views and handlers?

        Best regards,

        Daniel

        (0) 
        1. Former Member Post author

          Hello Daniel.

          Could you please check that you have implemented notes 1754488 and 1797961 in your system. Actually all view handlers are suppose to be in the public part ‘ExtensionRestricted’.

          Kind regards,

            Ralf

          (0) 
          1. Former Member

            Hi Ralf,

            Thanks for the notes. This helps. Now I am able to reuse the existing login view components and simply extend the UserLoginVCHandler to redirect to the application list. Furthermore I extend the AppListViewHandler which is responsible for the application list and overwrite the method prepareData(). I use your suggested code for that:

            FacesContext.getCurrentInstance().getExternalContext().redirect(redirectUrl);

            Due to the context of FacesContext.getCurrentInstance() was null we got a NullPointerException. I found out that the application-j2ee-engine.xml of dpu must have the following entry:

              <!–  JSF 2 Implementation –>
                <reference reference-type=”hard” prepend=”true”>
                    <reference-target provider-name=”sap.com”
                        target-type=”library”>wec~frw~tc~jsf~lib</reference-target>
                </reference>

            Now the forward works fine. Unfortunately, in the new application we have to login again. Thus I set the “Policy Configuration” property in the module user of the new application to “ticket”. It does not help. I also did a permission trace at the backend. It seems to be no permission issue.

            Why SSO does not work in this use case?

            Best regards,

            Daniel

            (0) 
            1. Former Member Post author

              Hello Daniel.

              Did you also set the policy configuration of the targetting web application to ‘ticket’. Both application need to be configured in this way (while ‘ticket’ is only an example and other SSO mechanism could also be used).

              Kind regards,

                Ralf

              (0) 
              1. Former Member

                Hello Ralf,

                Yes, I have also set the policy configuration of the target web application to ‘ticket’. In the meantime I found out the reason why SSO does not work.

                I used ‘Preview HTML’ to test my extensions. In the authentication logs I saw that in this case the ticket of the WCB user is used instead the ticket of the logged in user of the WC application. Therefore the SSO failed.

                After activation of the WC application and using the direct link it works fine.

                Thanks a lot! Our use case is implemented now.

                Best regards,

                Daniel

                (0) 
                1. Matthias Braeuer

                  Hi Daniel

                  Actually, I think in the case of WCB preview, SSO is disabled altogether. I came across that when I was first testing SSO between our web shop and an external application.

                  There is a JSF phase listener called PhaseListenerSSOHandlerApp that contains the following code:

                  // when running in Preview Mode override Policy Configuration to
                  // avoid SSO logon
                  if (wecSession.isWcbPreview()) {
                     confBo.setPolicyConfig(POLICY_CONFIG_FORM);
                  }
                  

                  Maybe that should be documented somewhere in the Security Guide actually, since it appears to be tripping off a few people.

                  Regards,

                  Matt

                  (0) 
  3. Former Member

    Hi Ralf

    Very good blog and I have similar requirement in my project, were Internet user /Customer to logon to his shop directly depending on the sales area he belongs to.

    The challenges which I see in my scenario that internet user might be a contact person for many customer/Sold to of different sales area.

    Step 1 User Log on

    Step 2 Sold to party selected (in case more then one then standard popup)

    Step 3 1 or multiple Sales area found then as per standard list of valid applications will be shown.

    Query 1 How to handle the scenario where logged on user is having different sales area then sales area defined in com.sap.common’ ?

    As for as my understanding goes application list is filtered on the basis of sales area maintained on com.sap.common and user sales area? Is that correct or worg ?

    Query 1 you maintained that the application must run with ‘User Storage Setting’ ‘UME’ or ‘UME only’. In our scenario User Storage Setting is “UME and ABAP “

    Is this must to use UME only?

    Is this only for landing application or for all the applications? 

    Regards

    Abhay

    (0) 
    1. Former Member Post author

      Hello Abhay.
      Your use case is not that easy. First the easiest part of the answer about UME. UME & ABAP is fine for your use case. More complicated are the different sales areas.

      I could imagine an approach like this. First use the solution of this blog to allow the user to select its sold-to party he want to work with. Now as the sold-to party defines the sales areas (even muliple sales areas could be assigned to a sold-to party) as second step is necessary to determine the web application fitting to the sales area of the choosen sold-to party. This all can be done within this central login application.

      Now as the user has selected the sold-to party and the web application, you can navigate/redirect to the web application itself. In case the user has only one sold-to assigned (fitting to the sales areas of this web application) he will be automatically logged in (that’s why in general UME is needed). If the user has more than one sold-to party assigned he would be again prompted to select one. If this application behaviour should be changed, you would need to adapt the PhaseListenerSSOHandlerApp.java

      Kind regards,
        Ralf

      (0) 

Leave a Reply