1

I know that my this question is more specific to JAVA application with less involvement of Tridion. But I personally, being a Tridion developer, would like to involve our community in this discussion. It will not be point of any concern if I or someone move this question to Stack Overflow later but my humble request to keep it with Tridion people for some moment because they also have JAVA(.net) knowledge.

I have to develop some secure JSP pages which are not linked anywhere in the website which is almost at their support stage. There is no authentication functionality implemented anywhere in this website. Requirements and challenges are as below -

(a) When any concern person will hit the URL of any JSP page. Page will ask for login Credentials.

(b) If credentials are correct, content of the Page will be displayed otherwise Error message “User id or password is wrong” will be shown to the person in the same login popup.

(c) Each JSP page will have a user id and password which should be manageable by Editors so that they can reset the credentials at any given time.

(d) Client does not have any database apart from Tridion and we cannot use Tridion databases for this.

(e) There is big challenge that client does not have budget for any big implementation such as web (WCF) services and data is not needed much security so he(she) can compromise with a bit with security at certain level (as mentioned in the “JavaScript Password protected page” approach)


Below are the implementation approaches and their individual limitations in my head:

1. JavaScript Password protected page

(a) In any case I have to place password in the client browser either by hardcoding it in to the JavaScript or browser cookies etc. Client agreed to this as long as password is encrypted and cannot be seen in the page’s source in human readable format. He(she) can compromise here with security at that level.

(b) How it is possible to hide the content of the page after popping up the login window. I am a bit unsure (not completely) that it may be possible through some sort of JavaScript and CSS.

2. HTTP BASIC authentication on the particular JSP page

We cannot publish the tomcat-users.xml file to provide the ability to reset the credentials by the Editors. or is it possible, please suggest here?

3. Secure folder which contains these pages using .htaccess

Even though we are running Apache we cannot secure folders using .htaccess as I found on Google that it works with .HTML pages only and here I have .JSP pages. I do not have enough knowledge on this point so please correct me if I am wrong here.

  • Is the intention here to have users register or to hold a "stock" username and password that they share? – Dave Forber Sep 5 '13 at 13:27
  • 2
    While I see your point to ask this question here, in my opinion it really does belong on Stack Overflow and not here. So I vote for this to be migrated... (mind you if you change point (d) to "Client does not want to use any databases for this.", it is a perfect question for on SO and a lot of the Tridion community members visit that site too) – Bart Koopman Sep 5 '13 at 13:31
  • No Dave,we are not providing user any such functionily( "register" or "forgot password" something) – user584 Sep 5 '13 at 13:31
  • Regarding #2, you can publish any text-based format, though not sure you'd want to manage (parts of) tomcat-users.xml in the CMS. – Alvin Reyes Sep 5 '13 at 19:02
6

I implemented something similar using Tridion and JSP. In my use-case, a user had to verify they'd read some terms and conditions before they could see the content of the page, but that's easily enough adapted to your use case where a stock username/password is set.

From memory, the process worked something like:

We assigned a protected component a category of "protected"

We wrote a C# TBB for Page Templates to find any components that had that category. If any of the components had that category, they were wrapped in a Java tag "protectedcontent", e.g.

<mytag:protectedcontent>
    <!-- Template Code -->
</mytag:protectedcontent>

The Java tag verified that the form had been submitted correctly (i.e. a checkbox had been ticked, but in this case it'd be your username/password)

The code in question (changed a little) :

package MyPackage.CustomTags;

import javax.servlet.ServletRequest;
import javax.servlet.http.HttpSession;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspTagException;
import javax.servlet.jsp.tagext.TagSupport;


public class ProtectedContent extends TagSupport {

    private static final long serialVersionUID = 1L;

    private String url;

    public void setUrl(String url) { //read the attribute url
        this.url=url;
    }   

    public int doStartTag() throws JspException {
        HttpSession session=pageContext.getSession(); //get a session
        ServletRequest request=pageContext.getRequest();
        if(request.getParameter("userHasAccepted")!=null) {
            if(request.getParameter("userHasAccepted").equals("accepted")) {
                session.setAttribute("userHasAccepted", "accepted"); //note that they've accepted so we don't show the page again
            }
        }
        else if(session.getAttribute("userHasAccepted")==null){
            return validateUserHasAccepted();
        }
        if(session.getAttribute("userHasAccepted").equals("accepted")) {
            return EVAL_BODY_INCLUDE; //display the content between the tags
        }
        else {
            return validateUserHasAccepted();
        }
    }

    public int doEndTag() {
        return EVAL_PAGE;
    }

    public int validateUserHasAccepted() throws JspException {
        try {
            pageContext.include(url); //this set via a tag attribute (can't quite remember where, probably in the PT)
        }
        catch (Exception ex) {
            throw new JspTagException(ex.getMessage());
        }
        return SKIP_BODY;
    }

}
  • 1
    I should add that this never actually saw the light of day, since the business eventually realised that there was little point in adding this "security". – Dave Forber Sep 5 '13 at 14:22
4

It seems to be a requirement for SCD (Secure Content Delivery), with SCD you indeed can manage the user roles in Tridion as metadata in folders/components/pages.

SCD will follow the same Java Security specification but it made tridion friendly.

Additionally you can use JAAS and a Tom Cat JAAS Realm, it will allow you to stop using the tom cat users file. With JAAS you can manage the users, roles and passwords in a database table or any other repository.

  • I agree on the SCD match, but that never made it to open source or community ware right? Which means the only way to get it (if it is still available) is to hire a SDL Tridion Consultant and have them implement it? With regards to JAAS, that doesn't match with the customer requirement to not have any additional databases I think. – Bart Koopman Sep 5 '13 at 14:06
  • well JAAS will allow you to implement an Authenticate method, that method will return true or false, that method can connect to a database or any other repository (like the tridion broker metadata), even to the tom cat users file. – Eric Huiza Sep 5 '13 at 14:13
  • Indeed as @BartKoopman is mentioning SCD is not open source and it should be implemented by an SDL Tridion Consultant. – Eric Huiza Sep 5 '13 at 14:23
  • 1
    Tridion SCD is indeed a commercial product, but the idea is "open". In other words - you have metadata in Tridion for managing authorization, and you publish it to make it available to your web application, which then uses the standard security mechanisms available on the platform to secure the content. – Dominic Cronin Sep 6 '13 at 7:46
3

To address the issue of not having a database, you can use something like Hypersonic SQL, Mongo DB or another text-file based DB, so you don't need a special installation or dedicated DB server. It just works as part of your web app.

You can then implement a simple authentication/authorization mechanism that doesn't need to rely on Tomcat, i.e. create a USER table in the DB with columns such as: USER_ID, PAGE_URL, ACCESS. In the java code add a login screen (controller) where you authenticate and authorize the user by checking the DB table, then set a User object into the session. Subsequently, check for the presence of this user object to be set in the session. If true, then all good, else redirect to login screen.

Regarding controlling the user list/administration of access, you can create a storage extension to publish the user list directly into your DB, or instead of a DB, just publish and XML file with values encrypted with something like MD5 (one way digest encryption).

  • 1
    I would like to add that it is better to put such a database outside of the webroot, as text based DBs with MD5 hashing can easily be hacked. – Raimond Sep 6 '13 at 7:59
  • 2
    Since the OP is already considering password protection via JavaScript then I don't think they are worried about anybody cracking their MD5 hash either. – Bart Koopman Sep 6 '13 at 9:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.