Well I was thinking about not logging in the subject and use a custom
subject factory, but I need the login functionality (in order to use
JdbcRealm to authenticate in the first step). The problem I am facing is
this: using the default behavior I'll get an authenticated user (at least
the isAuthenticated function returns true), so the second filter cannot
allow access only by checking if the user is authenticated. I believe are
there are many ways to solve this problem, and I taught using this one:
- authenticate user as usual in step one
- send the temporary password to user, _save_ it in _session_ (in order to
verify it in step 2) and redirect to second login page
- allow access in second login page if user is authenticated
- user sends the temporary password, and use a custom realm which does the
following:
a. check the user provided temporary password against the password
saved in session
b. if passwords match, assign _two_ principals to user (very important)
- Now the second filter will check if 2 conditions are met: one
isAuthenticated, two if it has the second principal in session.
I am wondering if there are any security problems, but as far as I can tell
everything looks ok.
On Fri, Feb 19, 2016 at 6:37 AM, Kalle Korhonen <[email protected]>
wrote:
> On Thu, Feb 18, 2016 at 12:17 PM, alexd92 <[email protected]>
> wrote:
>
>> @Kalle: no I don't want the remember me functionality, all I want is a
>> secure way to pass through two filters: one that permits access if user
>> can
>> provide a static pair of username and password, and a second one which
>> allows access if step one succeeds _and_ user provides a second, one time,
>> password.
>>
>
> Yes, that's exactly what I mean. If you don't need the rememberMe
> functionality for the designed purpose, then you can use it for this
> purpose. So, in step one, you create a subject but leave the authenticated
> as false. Then, in the step two, you only allow access to non-guest users
> and call login to create subject that's authenticated. Disable rememberMe
> cookies and probably easiest to simply create a custom SubjectFactory for
> step one instead of invoking login.
>
> Kalle
>
>
>> On Thursday, February 18, 2016, kaosko [via Shiro User] <
>> [email protected]> wrote:
>>
>> > Do you need the rememberMe functionality in addition to the two-factor
>> > authentication? If not, the first filter could easily make the user
>> > remembered and the second one authenticated. Or you could use a generic
>> > role to mark that the user needs or have completed the second phase
>> > authentication.
>> >
>> > Kalle
>> >
>> > On Thu, Feb 18, 2016 at 8:50 AM, Brian Demers <[hidden email]
>> > <http:///user/SendEmail.jtp?type=node&node=7580955&i=0>> wrote:
>> >
>> >> Thinking out loud here, so others feel free to chime in.
>> >>
>> >> As far as OTP goes, some systems use pin + token as a single line.
>> With
>> >> this case, you _could_ use a UserPasswordToken and have your
>> >> realm/authenticator check to see if the user has a OTP attribute set
>> or not.
>> >>
>> >> But for the multi form (similar to what google or gihub approach) your
>> >> idea with the auth filters might be a good approach. You could check
>> for
>> >> an existing of a role/permission "OTP" (or subject attribute) from a
>> >> filter, and then redirect to your other login page. Needing to force
>> the
>> >> subject logout is an interesting issue, I cannot think of an easy way
>> >> around this without overriding a few methods form the SecurityManager.
>> >>
>> >> Other thoughts on this?
>> >>
>> >>
>> >> On Thu, Feb 18, 2016 at 2:42 AM, alexd92 <[hidden email]
>> >> <http:///user/SendEmail.jtp?type=node&node=7580955&i=1>> wrote:
>> >>
>> >>> For the moment I'm thinking at the following solution:-use two
>> filters,
>> >>> f1
>> >>> and f2 and 2 realms (r1 and r2)-protect the urls: /login1 = anon,
>> >>> /login2 =
>> >>> f1, /** = f2-f1 = org.apache.shiro.web.filter.authc.UserFilter-f2 = {
>> >>> custom
>> >>> filter which permits access if user has 2 principals in session }-r1 =
>> >>> could
>> >>> be JdbcRealm-r2 = custom realm which adds two principals in session
>> >>> Short:- first login is annoymous, anyone could enter credentials- in
>> >>> case of
>> >>> succes it is redirected to second login page, where it has access only
>> >>> if it
>> >>> is authenticated (using r1)- if login2 succeeds it is redirected to
>> main
>> >>> page, and has access only if it passes the second filter, f2 (which it
>> >>> will,
>> >>> if the login2 succeeded).
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>>
>> http://shiro-user.582556.n2.nabble.com/Multifactor-authentication-tp7580952p7580953.html
>> >>> Sent from the Shiro User mailing list archive at Nabble.com.
>> >>>
>> >>
>> >>
>> >
>> >
>> > ------------------------------
>> > If you reply to this email, your message will be added to the discussion
>> > below:
>> >
>> >
>> http://shiro-user.582556.n2.nabble.com/Multifactor-authentication-tp7580952p7580955.html
>> > To unsubscribe from Multifactor authentication, click here
>> > <
>> http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7580952&code=ZGl0dS5hbGV4YW5kcnVAZ21haWwuY29tfDc1ODA5NTJ8LTE2MTg5OTk0MDE=
>> >
>> > .
>> > NAML
>> > <
>> http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>> >
>> >
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://shiro-user.582556.n2.nabble.com/Multifactor-authentication-tp7580952p7580956.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
>
