Sie sind hier

P8 Daphne: User authentication

There has been a fundamental change in the way how Authentication is handled between the FileNet Buzz API that came with P8 3.5.x and the new Daphne API architecture used from P8 4 on. In Buzz, Authentication information is attached to all Objects. Every operation on an object is executed in the context of the user that created the session this object has been retrieved from. In Daphne, user authentication is set up in the current thread. This method is closer to JAAS and it enables the same object to be used in the context of different users. The Daphne API manages a UserContext for every thread. This UserContext contains a stack of JAAS Subjects. Whenever an operation is performed, the JAAS Subject on the top of this stack is used for the Authentication at the Content Engine. If this stack is empty, the API tries to use the JAAS Subject assigned to the current thread in the Application Server. Before being able to perform any operation, an application needs to create a new JAAS Subject and push it on this stack. For command line or Desktop applications, you do not need to care about this stack after performing your operations. It is disposed when the VM ends. But in Web Applications, the thread is pushed back in the Application Servers thread pool and reused for the next incoming request. This opens a massive security problem if the application does not clean up Subjects it pushed on the stack. You always need to enclose your operations in try / finally and remove any Subjets you pushed on this stack at the end:

UserContext.get().pushSubject(subject);
try
{
// perform your operation here
}
finally
{
UserContext.get().popSubject();
}

Otherwise, any subsequent request handled by the same thread pool – even request handled by different applications – is able to perform operations at the CE in the context of the user Subject you pushed on the stack. These problems are very hard to detect in a web application. In most cases, you will notice that a user occasionally performs operations in the context of a different user, e.g. the user sees Documents in a folder without having proper Authorization for these or a Document is owned by a different user after a Checked-Out. To detect those problems, you can peek at the top of the Subject stack on every incoming request and check it for null:

UserContext.get().getSubject() == null

This stack has to be empty on a new incoming request. If not, any other application using the same thread pool can have left this Subject on the stack.

Tags: