Skip to Content
An often overlooked restriction of KM is that it doesn’t support anonymous users (see the SAP EP Security Guide.) While I can’t explain the technical reasons behind this restriction (I simply don’t know them — perhaps one of the readers does?:-)), I was challenged to find a work around for a customer.
style=”font-weight: bold;”>
The Scenario
This customer was building a corporate web-site using SAP EP 6 SP2. To be accurate, it was style=”font-style: italic;”>11 different web-sites on a style=”font-style: italic;”>single SAP EP. Their weapon of choice for content management: KM (the obviuos companion to EP), and they’ve made a decision to use Display Rules (based on the logged-on user ID) to select the appropriate portal desktop layout and design. Since this is a style=”font-style: italic;”>public was site no login was possible, and so the Named Anonymous User concept was selected. Unfortunately, they overlooked the KM restriction regarding anonymous users, and were already pretty deep into the implementation to make an architectural change when they found out this was not supported.

style=”font-weight: bold;”>The Quick-‘n’-Dirty Solution
The quick-and-dirty solution would be to create normal users and make them automatically login into the system. This is achievable by adding a few parameters to the URL sent to the PortalLauncher component:

  1. j_user: should have the user’s ID
  2. j_password: should have the user’s password
  3. login_submit: must have the value ‘true’

the “login_submit=true” parameter is crucial — it tells the login-page to behave as if the user just clicked the “Login” button, thus hiding the login-page from the user.

style=”font-weight: bold;”>In Comes the Authentication Scheme
The next step was to make this ‘hack’ production-grade. The most obvious problem here is content security — we’re basically letting users authenticate as regular users (which must have the End-User role) without ever requiring a password (hell, we’re even giving away the password in the URL). Once in have the permissions to activate all sorts of iViews we don’t want them to.
To solve this we turned to Authentication Schemes. In a nutshell, authentication schemes are different ways for users to login to the portal. The default one for example requires a user-id and password combination. An auhentication scheme which allows login with client-certification is also available with the portal, along with a few others (Authentication Schemes are part of JAAS standard implemented in the SAP J2EE Engine — you can read the Portal Security Guide to learn more about it.)
One of the important features of authentication schemes is that they can be prioritized. For example you can set the certificate authentication scheme to a higher priority then the user-id/password authentication scheme. Portal Objects have an Authentication Scheme property in which you can select what is the minimal required authentication scheme which a user needs to log-on with to view gain access to that content. This means that you could, for example, make administrative objects available only to users who logged in using a client-certificate to beef up security.
Enough with JAAS 101 — back to the issue in hand, we wanted to restrict the automagically logged on users to be have access only to exactly what we want them, while still being able to allow content and system administrators to have access to what they need. To do this we created a new authentication scheme with a very low priority (priority set to 2; 20 is the default, 0 is anonymous), and set the content web-site visitors need to access to require only that authentication scheme. (to learn the process of adding an authentication scheme see the JAAS documentation mentioned above.) This new authentication scheme was basically a copy of the style=”font-style: italic;”>uidpwd scheme (the default one), with the priority changed. To make users logon using that authentication scheme we add yet another parameter to the URL sent to the logon-page:
style=”font-style: italic;”>j_authscheme=schemename

style=”font-weight: bold;”>Taking it Up A Notch
This is almost enough — users can still omit the style=”font-style: italic;”>j_authscheme parameter and log-in with the default authentication scheme…. this is a tough cookie — there’s no way to create an access-list for authentication schemes. A possible solution is to disable the standard user-id/password authentication scheme, and keep only the custom one and a more secure one like client-certificate which requires per-user setup.
The last thing we wanted to do is to make sure only the predefined users which are used for the display rules are allowed to log-in with our authentication scheme. Again, there’s no built in way to do it, so we created a custom Login Module. Login Modules are the building blocks of authentication schemes (this is again part of the JAAS standard.) — a login module for example would know how to read a user’s client-certificate and validate the user is allowed to login. Our Login Module read the supplied user-id and compared it to a (configurable) users list which are allowed to use this authentication scheme.
You can find a good tutorial about Login Modules here. We then changed our authentication scheme to use the custom login module, and we were done.

style=”font-weight: bold;”>Summary
At the end, we got from a non-supported, problematic solution based on named anonymous users to a fully supported, secure solution based on industry-standards, which we know will be easily ported to the NW’04.

To report this post you need to login first.

2 Comments

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

    1. Actually, note 728106 talks about KM _iViews_, not components. Technically, you might get it to work. The problem is getting support for such a solution.
      (0) 

Leave a Reply