Creating code with Apache Sling, CQ5 and Adobe Experience Manager in the past had a problem that has a very easy, but dangerous, solution.

Sessions Easy to Come By If Your Code is a Servlet

Inside of servlets and JSP (within Apache Sling JSP are compiled as servlets), the code is executing in the context of a specific user. A user-based session can easily be obtained. But once code is outside the world of servlets, getting a session can be problematic.

Sessions act as gatekeepers for the JCR. If a user has access to content in the JCR, the session knows. Otherwise, the user does not even know if the content is there. Each session considers all of the restrictions and provides the proper access to the JCR. This is a great security feature. If a person manages to do SQL injection with Sling, the only thing they would be able to read or write are the things they has permission to read and write. Sessions sandbox code.

Hey Bud, You Have a Session You Can Spare?

If a developer doesn’t have a session, but needs one, there were a couple of alternatives before AEM 6. A developer could use a predefined user name and password to log in. They could require a session be passed as an argument so user-based sessions can be shared in user-agnostic code. They can use the magic key, the administrator session.

Using a user name and password means saving a user name and password somewhere. Not necessarily a good thing. If a saved in a user-agnostic area, any user theoretically has access to the saved user name/password. If coded into distributed code, the username/password combination becomes inflexible.

Sharing sessions can lead to problems with memory leaks or sessions closing when they shouldn’t.

The left a solution to the problem that was short and easy to use: get and use an administrative session. The Apache Sling world has dutifully left open a back door to administrator access that any developer can use in the form of administrator sessions. Administrator sessions can be accessed using a couple of different methods:

Friends Don’t Let Friends Use Admin Sessions

One problem with the super magic key of an admin session is that it gives code access to everything. That makes it even more important that code cannot be exploited when an admin session is used.

It would be good if services could be limited to a sandbox, wouldn’t it?

Service Users FTW

The ability to associated users with services has been introduced in AEM 6. Each service can have its own user or it can share a user with one or more other services. Appropriately enough, these type of sharable users are called service users.

Service users can be defined using sling:OSGiConfig nodes or within the Felix configuration console.

To take advantage of these new types of users, new methods have been defined to wean the coding-folk off of administrator sessions:

All is Not Happy Love Happy

One restriction right now (December 2014) is that service user management and, more importantly, service user access management, can be a chore as the number of services and service users increase. A good solution does not exist, yet, to make the management of service users easy and fun for the whole family. It is still worth the effort to use service user sessions instead of admin sessions. Using service users allows the developer to write more secure code. And we all know that secure code is a Good Thing. We like Good Things.

In Conclusion

Use service users and service user sessions. Don’t use admin sessions.

More Information

About The Author

Deke departed Southern Alabama as a young man, leaving the humidity and fire ants behind. The fire ants are catching up with him. He works for Adobe. Despite that, his opinions expressed on this site are his own and should never, ever, be attributed or blamed on Adobe. Ask him what he thinks of chiggars sometime. Home Page | GitHub | Adobe Blog | Twitter | LinkedIn