Martin Nybo Nielsen created SHIRO-646:
-----------------------------------------
Summary: Unable to login a DelegatingSubject on a
DefaultWebSecurityManager
Key: SHIRO-646
URL: https://issues.apache.org/jira/browse/SHIRO-646
Project: Shiro
Issue Type: Bug
Components: Authentication (log-in)
Affects Versions: 1.4.0-RC2
Reporter: Martin Nybo Nielsen
When programatically creating a DefaultWebSecurityManager, it is not possible
to login a DelegatingSubject, for example built through Subject.Builder.
The problem is twofold.
First, in DefaultWebSecurityManager, no SessionManager is set for the
DefaultWebSessionStorageEvaluator unless the DefaultSubjectDAO is set through
the DefaultWebSecurityManager.setSubjectDAO method. The DefaultSubjectDAO and
DefaultWebSessionStorageEvaluator set in the noargs constructor in
DefaultWebSecurityManager does not set a SessionManager for the
DefaultWebSessionStorageEvaluator. The null SessionManager means that the
DefaultWebSessionStorageEvaluator will always decide to create a Session for
the DelegatingSubject, which will fail due to it not having a a HTTP
compatible session. The error occurs in ServletContainerSessionManager here:
protected Session createSession(SessionContext sessionContext) throws
AuthorizationException {
if (!WebUtils.isHttp(sessionContext)) {
String msg = "SessionContext must be an HTTP compatible implementation.";
throw new IllegalArgumentException(msg);
}
Second, The DefaultWebSubjectFactory will ALWAYS create a WebDelegatingSubject
when logging in a Subject, no matter if the Subject was, for example a
Delegating Subject to begin with.
The order of events is a follows:
DelegatingSubject is created through Subject.Builder.
DelegatingSubject.login(AuthToken) is called.
DefaultSecurityManager.login(Subject, AuthenticationToken) is called which in
turn calls createSubject(AuthenticationToken, AuthenticationInfo, Subject).
Since we are using a DefaultWebSecurityManager, createSubjectContext() returns
a DefaultWebSubjectContext.
When DefaultWebSubjectFactory is then called on to create a new Subject, it
recieves a DefaultWebSubjectContext even though the DelegatingSubject was the
caller.
That means that a WebDelegatingSubject is created with a null ServletRequest
and ServletResponse.
That fails when again in the ServletContainerSessionManager here (The same
place as before):
protected Session createSession(SessionContext sessionContext) throws
AuthorizationException {
if (!WebUtils.isHttp(sessionContext)) {
String msg = "SessionContext must be an HTTP compatible implementation.";
throw new IllegalArgumentException(msg);
}
The fix is twofold, and i will create a Pull Request for it:
Change the noargs constructor in DefaultWebSecurityManager so the
DefaultWebSessionStorageEvaluator has a SessionManager set.
Introduce a check in DefaultWebSubjectFactory which checks if the existing
Subject was NOT a WebSubject, and call the super.createSubject(context) method
if so.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
