11:33 a.m.
Bill,
right. Session is the key. We did have a discussion that coincided
with your thoughts.
Copying here:
=========
(10:55:43 AM) asaldhan: psilva: is my email clear or I need to add more
information?
(10:56:12 AM) psilva: asaldhan: for me is clear.
(10:58:20 AM) psilva: asaldhan: i think the credential api ca support
multi stage authentication. But u need to create a custom
credential/handler/storage.
(10:58:26 AM) psilva: can
(10:58:29 AM) asaldhan: psilva: right
(10:58:35 AM) asaldhan: psilva: but we do not have stage hooks
(10:59:09 AM) asaldhan: psilva: like setStage(1,
Password.class).setStage(2,OTP.class);
(10:59:24 AM) asaldhan: pbox
(10:59:28 AM) psilva: i see ...
(11:04:04 AM) psilva: let's take the bank example. when you receive a
sms with a code to proceed with your transaction. before sending the sms
you update a specific credential type with a expiry date (eg.: 1 hr).
The app redirects the user to a page where he must fill the code. The
user type the code and submit to the app. The app get the code and try
to validate the credential. If the code is correct and user is inside
the valid period, fine.
(11:05:02 AM) psilva: this scenario is possible, i think, using what the
idm have.
(11:09:25 AM) jherson left the room (quit: Quit: Leaving).
(11:09:27 AM) asaldhan: psilva: it is not the IDM but I think we have to
deal something at the session level
(11:09:43 AM) asaldhan: psilva: like the session needs to store where
the current stage the user has reached.
(11:09:57 AM) asaldhan: psilva: the IDM can hold the stages the
application supports
(11:10:10 AM) asaldhan: psilva: but for each user, the current state is
held at the session level
(11:10:14 AM) psilva: asaldhan: got your point.
(11:10:34 AM) asaldhan: psilva: I dont think we need this usecase
implemented right now. we have to do it post pb5
(11:10:42 AM) psilva: asaldhan: pbox can handle that.
(11:10:44 AM) psilva: asaldhan: ok
(11:11:03 AM) asaldhan: psilva: since session supports attributes, I
think it can support.
(11:11:33 AM) asaldhan: psilva: but developer needs to define
application.setstages(3).setstage(1,password).setstate(2.otp)
(11:11:42 AM) asaldhan: psilva: that information needs to sit in the IDM IMO
(11:11:53 AM) asaldhan: psilva: maybe Agent.attributes can be used for now
(11:12:11 AM) psilva: asaldhan: seems like a workflow management ...
(11:12:17 AM) asaldhan: psilva: right
(11:12:40 AM) asaldhan: psilva: IDM processes are workflows
(11:13:15 AM) psilva: asaldhan: maybe some integration with jbpm :)
==========
On 01/25/2013 11:20 AM, Bill Burke wrote:
So, you need the concept of a session. Something you don't need
in the
web tier, but will need in other tiers.
On 1/25/2013 11:47 AM, Anil Saldhana wrote:
> Hi All,
> I have been thinking about the multi stage authentication process
> that Bill has been mentioning. Basically, the discussions have been
> confusing between multi mechanism authentication vs multi stage
> authentication.
>
> In multi mechanism authentication, the framework needs to support
> multiple authentication mechanisms such as Credential, X509, OTP, Custom
> etc, given different entry points into the application -> browser,
> mobile, rest etc.
>
> In multi stage authentication, the framework needs to provide hooks to
> define the stages in a complex authentication process for high risk
> applications such as banking, credit etc.
>
> Some of the stages are highlighted here:
> credential ------> Knowledge based authentication (Questions and
> Answers) --------------->Index Page
> credential -------> KBA ------------> Mobile SMS Code
> -------------> Money Transfer Page
>
> credential ------> OTP -----------> Index Page
>
> credential ----------> Index Page ---------> OTP ----------> Money
> Transfer Page
>
> Generically:
> stage1 -------> stage2 -------------> Resource
>
> So if there is an application developer who wishes to incorporate stages
> into the authentication process, he can use the IDM underneath to hold
> the state of the stages as well as will need hooks into defining the
> authentication type for each stage.
>
> Thoughts?
>
> Regards,
> Anil
> _______________________________________________
> security-dev mailing list
> security-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>