shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Nielsen <mny...@gmail.com>
Subject Re: Authenticating a Subject without a session with a WebSecurityManager
Date Tue, 10 Apr 2018 08:29:10 GMT
I mailed the ICLA to  secretary@apache.org this morning

On Mon, Apr 9, 2018 at 3:50 PM, Brian Demers <brian.demers@gmail.com> wrote:

> Thanks!! I left a few minor comments and a pointer to the Apache icla:
> https://www.apache.org/licenses/icla.pdf
>
> IIRC, the use of NATIVE_SESSION_MODE and/or DefaultWebSessionManager,
> reverts to the non-web DefaultSessionManager when there is no web context.
>
> On Mon, Apr 9, 2018 at 6:17 AM, Martin Nielsen <mnybon@gmail.com> wrote:
>
>> I created a jira issue SHIRO-646
>> <https://issues.apache.org/jira/browse/SHIRO-646> as well as a pull
>> request https://github.com/apache/shiro/pull/82
>>
>> The pull request contains a test and two fixes to make the test pass.
>>
>> A small note to something I didn't check up on:
>> Calling
>> DefaultWebSecurityManager.setSessionMode(DefaultWebSecurityM
>> anager.NATIVE_SESSION_MODE);
>> makes the error disappear. I can't invest more time in it right now,
>> sorry.
>>
>> I hope to check up on it in a few days if no one can explain it outright,
>> but trawling though all those classes has been a lengthy, albeit
>> interesting learning experience :)
>>
>> -Martin
>>
>> On Fri, Apr 6, 2018 at 3:29 PM, Brian Demers <brian.demers@gmail.com>
>> wrote:
>>
>>> Cool, that sounds like something we should be able to write a simple
>>> test for too!
>>>
>>> On Fri, Apr 6, 2018 at 8:50 AM, Martin Nielsen <mnybon@gmail.com> wrote:
>>>
>>>> Hi Brian
>>>>
>>>> I looked a bit further at the issue and i will create a bug report when
>>>> i have the chance. The websubject created by the login method ends up
>>>> having both httpservlet response and requests set to null. That seems to
be
>>>> a pretty straight forward error. I fixed the issue by creating a new
>>>> websubject factory which creates delegatingsubjects instead of websubjects
>>>> if the existing subject was itself a delegatingsubject. No second
>>>> securitymanager needed, at least for now.
>>>>
>>>>
>>>> On Thu, 5 Apr 2018, 16:22 Brian Demers, <brian.demers@gmail.com> wrote:
>>>>
>>>>> Hey Martin,
>>>>>
>>>>> Take a look at the few sections following:
>>>>> https://shiro.apache.org/session-management.html#disabling-s
>>>>> ubject-state-session-storage
>>>>> Though I agree throwing an exception in this case probably isn't the
>>>>> best default.
>>>>>
>>>>> I had a similar problem a while back and IIRC I solved it by
>>>>> configuring a second SecurityManager (one configured for web access and
the
>>>>> second for non-web).  I had a few other differences configured as well,
but
>>>>> this approach means you need to manage the lifecycle of the second
>>>>> instance.
>>>>>
>>>>> If that first link doesn't get you what you need, think about the
>>>>> second option.  But either way please create a JIRA!
>>>>>
>>>>>
>>>>> On Thu, Apr 5, 2018 at 5:49 AM, Martin Nielsen <mnybon@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Right. So i got a little further, and discovered that the problem
is
>>>>>> the SessionStorageEvaluator on the DefaultSubjectDAO. It is set to
>>>>>> a DefaultWebSessionStorageEvaluator, seems like it should handle
the
>>>>>> problem with this code:
>>>>>>
>>>>>> //SHIRO-350: non-web subject instances can't be saved to web-only
>>>>>> session managers:
>>>>>>         //since 1.2.1:
>>>>>>         if (!(subject instanceof WebSubject) && (this.sessionManager
>>>>>> != null && !(this.sessionManager instanceof NativeSessionManager)))
{
>>>>>>             return false;
>>>>>>         }
>>>>>>
>>>>>> The problem is that when i login, the DelegatingSubject i create
is
>>>>>> automatically changed to a WebDelegatingSubject, which means that
this code
>>>>>> is skipped.
>>>>>>
>>>>>> What happens is this:
>>>>>>
>>>>>> shiroSubject = subjectBuilder.buildSubject();
>>>>>> Builds a DelegatingSubject, which passes through the Evaluator
>>>>>> without issue.
>>>>>>
>>>>>> shiroSubject.login(new UsernamePasswordToken(user, password));
>>>>>> Seems to have some unfriendly behavior as
>>>>>> the DefaultWebSecurityManager delegates its login
>>>>>> to DefaultSecurityManager, which creates a new Subject in its login
method
>>>>>> which becomes a WebDelegatingSubject thanks to the DefaultWebSubjectFactory
>>>>>> set by the  DefaultWebSecurityManager, which also
>>>>>> overrides createSubjectContext()  to return
>>>>>> a DefaultWebSubjectContext.
>>>>>>
>>>>>> In short: It seems no matter what i do, a WebDelegatingSubject is
>>>>>> ALWAYS created when i call the login method, causing the
>>>>>> DefaultWebSessionStorageEvaluator to attempt to create a session
for
>>>>>> a  WebDelegatingSubject which does not have a session as it was
>>>>>> created from a normal DelegatingSubject.
>>>>>>
>>>>>> This does seem more a bug than by design, and if people shout "bug"
i
>>>>>> will gladly create a decent bug-report. But for now: How on earth
do i get
>>>>>> around this?
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 5, 2018 at 9:23 AM, Martin Nielsen <mnybon@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all
>>>>>>>
>>>>>>> I have an application which uses a WebSecurityManager in conjunction
>>>>>>> with Apache Wicket. That works all well and good, but now I have
>>>>>>> encountered a single issue where i need to authenticate a user
through a
>>>>>>> different entrance, which does not have any notion of http sessions.
When i
>>>>>>> try to login a Subject without a session like this:
>>>>>>>
>>>>>>> Subject shiroSubject = null;
>>>>>>> Subject.Builder subjectBuilder = new Subject.Builder(manager).sessi
>>>>>>> onCreationEnabled(false);
>>>>>>> shiroSubject = subjectBuilder.buildSubject();
>>>>>>> ...
>>>>>>> shiroSubject.login(new UsernamePasswordToken(user, password));
>>>>>>>
>>>>>>> I tried every permutation of sessionCreationEnabled
>>>>>>>
>>>>>>>
>>>>>>> I get the following exception:
>>>>>>>
>>>>>>>
>>>>>>> javax.security.auth.login.LoginException:
>>>>>>> java.lang.IllegalArgumentException: SessionContext must be an
HTTP
>>>>>>> compatible implementation.
>>>>>>> at org.apache.shiro.web.session.mgt.ServletContainerSessionMana
>>>>>>> ger.createSession(ServletContainerSessionManager.java:103)
>>>>>>> at org.apache.shiro.web.session.mgt.ServletContainerSessionMana
>>>>>>> ger.start(ServletContainerSessionManager.java:64)
>>>>>>> at org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsS
>>>>>>> ecurityManager.java:152)
>>>>>>> at org.apache.shiro.subject.support.DelegatingSubject.getSessio
>>>>>>> n(DelegatingSubject.java:336)
>>>>>>> at org.apache.shiro.subject.support.DelegatingSubject.getSessio
>>>>>>> n(DelegatingSubject.java:312)
>>>>>>> at org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(Defau
>>>>>>> ltSubjectDAO.java:204)
>>>>>>> at org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(Default
>>>>>>> SubjectDAO.java:166)
>>>>>>> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDA
>>>>>>> O.java:147)
>>>>>>> at org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecu
>>>>>>> rityManager.java:383)
>>>>>>> at org.apache.shiro.mgt.DefaultSecurityManager.createSubject(De
>>>>>>> faultSecurityManager.java:350)
>>>>>>> at org.apache.shiro.mgt.DefaultSecurityManager.createSubject(De
>>>>>>> faultSecurityManager.java:183)
>>>>>>> at org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSec
>>>>>>> urityManager.java:283)
>>>>>>> at org.apache.shiro.subject.support.DelegatingSubject.login(Del
>>>>>>> egatingSubject.java:256)
>>>>>>>
>>>>>>> I then looked at WebSubject.Builder i can't create a builder
without
>>>>>>> a Request and Response.
>>>>>>>
>>>>>>>
>>>>>>> So the question is: When you are using a WebSecurityManager,
how do
>>>>>>> you authenticate a Subject in a case where there is no Request/Response
>>>>>>> available?
>>>>>>>
>>>>>>> The only way that I can see is to highjack the WebSecurityManager's
>>>>>>> Authenticator and Authorizer and call their methods directly,
completely
>>>>>>> ignoring the Subject, but that feels so wrong that I am guessing
that i am
>>>>>>> way off :)
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>

Mime
View raw message