From user-return-7661-archive-asf-public=cust-asf.ponee.io@shiro.apache.org Tue Apr 10 15:52:17 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id B83AE18067B for ; Tue, 10 Apr 2018 15:52:15 +0200 (CEST) Received: (qmail 67110 invoked by uid 500); 10 Apr 2018 13:52:14 -0000 Mailing-List: contact user-help@shiro.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@shiro.apache.org Delivered-To: mailing list user@shiro.apache.org Received: (qmail 67098 invoked by uid 99); 10 Apr 2018 13:52:14 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Apr 2018 13:52:14 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 42B6DC03DE for ; Tue, 10 Apr 2018 13:52:14 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.88 X-Spam-Level: * X-Spam-Status: No, score=1.88 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id Y-pjrmGSPtxI for ; Tue, 10 Apr 2018 13:52:10 +0000 (UTC) Received: from mail-ot0-f178.google.com (mail-ot0-f178.google.com [74.125.82.178]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 6E7E15FBAF for ; Tue, 10 Apr 2018 13:52:10 +0000 (UTC) Received: by mail-ot0-f178.google.com with SMTP id y46-v6so12797277otd.4 for ; Tue, 10 Apr 2018 06:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ar+ucI8yReMjOy9lQBrSTZa9NE4iwzubm0fBAwfAucI=; b=i3tyHH15yBKxDF6X9Q3ptl3lWSAIKoD2oI4hy9gLYexSftz0/ErDuUm2INLnhPvEFj lonOVHs8tB/WV3iV5SLuV7A8oalmYffUMg/DT/rlHlPiR0NBwWDzv4LrQpO9oSl0OOVw 9y1SZpK+wHZa1ZZZ2wIixTeVfmBf/cOUXxO5babultHNb9uJ+bIi+g0Koa4FvZnSSPTn TXtPgZ6D4X+5FZchdSpNC/Fi8rcelAi9iwrCpIHKucflVNa+SsPk42uG/KnGWLCmQkOk dcB4mJL5kMMYTWXAhO+Yji75d+UKXkkuPi5FXHkq/SVjXGNDYJYrkLLiDQnrIS/eKRDG oL4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ar+ucI8yReMjOy9lQBrSTZa9NE4iwzubm0fBAwfAucI=; b=bIa8Hf5MOrES2pmxGnlN+04ShBKGMTU/K33Riy9mmqjGvmInPUwqk9cRAuCAuj+uXM TkD8E5NEYoOlc3QrlBTJEhgd+R5FT2QxBq5EnzA4VvrAUHzfBFl7GrUPkLEXed+dbzqN O7XNDw8U+SDRzoeuUPEbkDUZQJWZRVG6w4x2b7zZ8DS1R8fWJkotii77N3pRQB6i7F+D D5ZwBZ3xcJVZke8Dj9T88P1b88KQZicV8BW620+ASqV715KtLpZX5BbT/7DzoPaU+Rjg nzq4BAahf9cLeLACAyoC8ZzYjUm5EcNDK8VD/WOcmUd77XM72acIDnG6ruMpt2Kr79ON WmLA== X-Gm-Message-State: ALQs6tA/SQlAuJXcujefWPSJJVfrWs1BHmmnrYXtAjaiUtd3xZzWXVGO NOvhhHsfAexEWCN3v14PbvCWZGQUBipnPb6zvFDMNA== X-Google-Smtp-Source: AIpwx4/c8VCkw+ymr9GN4a5bJIcz2RPbrbQp69FN8YyIkz4vpeOJXiwyL4XI0hUGKg5fBg8LqzkLiMB5j5WzB1f9g/w= X-Received: by 2002:a9d:48eb:: with SMTP id a40-v6mr390216otj.86.1523368329486; Tue, 10 Apr 2018 06:52:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.138.0.147 with HTTP; Tue, 10 Apr 2018 06:52:08 -0700 (PDT) In-Reply-To: References: From: Brian Demers Date: Tue, 10 Apr 2018 09:52:08 -0400 Message-ID: Subject: Re: Authenticating a Subject without a session with a WebSecurityManager To: user@shiro.apache.org Content-Type: multipart/alternative; boundary="00000000000024296005697ed4e0" --00000000000024296005697ed4e0 Content-Type: text/plain; charset="UTF-8" Great!! On Tue, Apr 10, 2018 at 4:29 AM, Martin Nielsen wrote: > I mailed the ICLA to secretary@apache.org this morning > > On Mon, Apr 9, 2018 at 3:50 PM, Brian Demers > 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 wrote: >> >>> I created a jira issue 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 >>> 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 >>>> 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, >>>>> 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 >>>>>> 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 >>>>>>> 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 :) >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>> >> > --00000000000024296005697ed4e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great!!

On Tue, Apr 10, 2018 at 4:29 AM, Martin Nielsen <mnybon@gmail.= com> wrote:
I mailed the ICLA to=C2=A0 secretary@ap= ache.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:=C2=A0https://www.apache.= org/licenses/icla.pdf

IIRC, the use of NATIVE_S= ESSION_MODE and/or=C2=A0DefaultWebSessionManager, reverts to the non-w= eb DefaultSessionManager when there is no web context.
=

On Mon, Apr 9, 20= 18 at 6:17 AM, Martin Nielsen <mnybon@gmail.com> wrote:
I created a jira issue=C2=A0<= a class=3D"m_-7997899286728555379m_-7232926942307408126m_-68737126629412599= 17gmail-issue-link" href=3D"https://issues.apache.org/jira/browse/SHIRO-646= " id=3D"m_-7997899286728555379m_-7232926942307408126m_-6873712662941259917g= mail-key-val" rel=3D"13150992" style=3D"font-family:Arial,sans-serif;font-s= ize:14px;color:rgb(59,115,175);text-decoration-line:none" target=3D"_blank"= >SHIRO-646=C2=A0as well as a pull request=C2=A0https://github.com/apach= e/shiro/pull/82=C2=A0=C2=A0

The pull request contain= s a test and two fixes to make the test pass.

A sm= all note to something I didn't check up on:=C2=A0
Calling
DefaultWebSecurityManager.setSessionMode(DefaultWebSecurityManager.NATIVE_SESSION_MODE);
makes the error disappear. I can&#= 39;t invest more time in it right now, sorry.

I ho= pe to check up on it in a few days if no one can explain it outright, but t= rawling though all those classes has been a lengthy, albeit interesting lea= rning experience :)

-Martin
<= /font>

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 F= ri, 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 websu= bject 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 deleg= atingsubjects instead of websubjects if the existing subject was itself a d= elegatingsubject. No second securitymanager needed, at least for now.
<= div class=3D"m_-7997899286728555379m_-7232926942307408126m_-687371266294125= 9917m_-7866843769900893292h5">

On Thu, 5 Apr 2018, 16:22 Brian Demers, <brian.demers@gmail.com= > wrote:
Hey Ma= rtin,

Though I agree throwing an exception in this case probab= ly isn't the best default.

I had a similar pro= blem a while back and IIRC I solved it by configuring a second SecurityMana= ger (one configured for web access and the second for non-web).=C2=A0 I had= a few other differences configured as well, but this approach means you ne= ed to manage the lifecycle of the second instance.=C2=A0=C2=A0
If that first link doesn't get you what you need, think ab= out the second option.=C2=A0 But either way please=C2=A0create a JIRA!


On Thu, Apr 5, 2018 at 5:49 AM, Martin Nielsen <<= a href=3D"mailto:mnybon@gmail.com" rel=3D"noreferrer" target=3D"_blank">mny= bon@gmail.com> wrote:
Right. So i got a little further, and discovered that the probl= em is the SessionStorageEvaluator on the DefaultSubjectDAO. It is set to a= =C2=A0DefaultWebSessionStorageEvaluator, seems like it should handle t= he problem with this code:

//SHIRO-350: non-web sub= ject instances can't be saved to web-only session managers:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 //since 1.2.1:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 if (!(subject instanceof WebSubject) && (this.sessionManager= !=3D null && !(this.sessionManager instanceof NativeSessionManager= ))) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

The problem is that when i logi= n, the DelegatingSubject i create is automatically changed to a WebDelegati= ngSubject, which means that this code is skipped.

What happens is this:

shiroSubject =3D subje= ctBuilder.buildSubject();
Builds a DelegatingSubject, which passe= s through the Evaluator without issue.

shiroSu= bject.login(new UsernamePasswordToken(user, password));
Seems= to have some unfriendly behavior as the=C2=A0DefaultWebSecurityManager del= egates its login to=C2=A0DefaultSecurityManager, which creates a new Subjec= t in its login method which becomes a WebDelegatingSubject thanks to the=C2= =A0DefaultWebSubjectFactory set by the=C2=A0 DefaultWebSecurityManager, which also overrides= =C2=A0createSubjectContext()=C2=A0 to return a=C2=A0DefaultWebSubjectC= ontext.

In short: It seems no matter what i do, a WebDelega= tingSubject is ALWAYS created when i call the login method, causing the=C2= =A0 DefaultWebSessionStorageEvaluator to attempt= to create a session for a=C2=A0 WebDelegatingSubject=C2=A0which does not ha= ve a session as it was created from a normal DelegatingSubject.

<= div>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 N= ielsen <mnybon@gmail.com> wrote:
Hi all

I have an applicat= ion 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 h= ave any notion of http sessions. When i try to login a Subject without a se= ssion like this:

Subject shiroSubject =3D null;
Subject.Builder subjectBuilder =3D new Subject.Builder(manager)= .sessionCreationEnabled(false);
shiroSubject =3D subject= Builder.buildSubject();
...
shiroSubject.login(new = UsernamePasswordToken(user, password));

I trie= d every permutation of sessionCreationEnabled


=
I get the following exception:


javax.security.auth.login.LoginException: java.lang.Illega= lArgumentException: SessionContext must be an HTTP compatible implemen= tation.
at org.apach= e.shiro.web.session.mgt.ServletContainerSessionManager.createSess= ion(ServletContainerSessionManager.java:103)
at org.apache.shiro.web.session.mgt.Serv= letContainerSessionManager.start(ServletContainerSessionManager.j= ava:64)
at org.apach= e.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager= .java:152)
at org.ap= ache.shiro.subject.support.DelegatingSubject.getSession(Delegatin= gSubject.java:336)
a= t org.apache.shiro.subject.support.DelegatingSubject.getSession(D= elegatingSubject.java:312)
= at org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(Defau= ltSubjectDAO.java:204)
= at org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(Defaul= tSubjectDAO.java:166)
= at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDA= O.java:147)
at = org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityM= anager.java:383)
at = org.apache.shiro.mgt.DefaultSecurityManager.createSubject(Default= SecurityManager.java:350)
<= /span>at org.apache.shiro.mgt.DefaultSecurityManager.createSubject(De<= wbr>faultSecurityManager.java:183)
at org.apache.shiro.mgt.DefaultSecurityManager.login(De= faultSecurityManager.java:283)
at org.apache.shiro.subject.support.DelegatingSubject.= login(DelegatingSubject.java:256)

I the= n looked at WebSubject.Builder i can't create a builder without a Reque= st and Response.


So the question is= : When you are using a WebSecurityManager, how do you authenticate a Subjec= t in a case where there is no Request/Response available?

The only way that I can see is to highjack the WebSecurityManager&#= 39;s Authenticator and Authorizer and call their methods directly, complete= ly ignoring the Subject, but that feels so wrong that I am guessing that i = am way off :)







--00000000000024296005697ed4e0--