Hi all.
I just have a question and a suggestion about this "run as" feature to
be implemented.
Is Subject sufficient for "run as" method? Shouldn't this method take
the same things as login(), which is a security token? The reason
being, that if you imagine uesrA is authenticated, and is prompted for
another username and passwd (as in windows) to allow access to another
part of the application. Then we can't just provide only the Subject
which is just like a username. Or am I missing something here about
Subject? Additionally, considering how many new laptop have the option
for fingerprint reader and who knows what's next, the token can be
anything, an image that can be passed to the realm to be compared.
Ok, so my suggest is that the 'run as' method take a token. I am no Ki
expert, so please forgave me if I have missed some essential part of
this discussion.
Thanks for Ki.
.v
Les Hazlewood wrote:
Hi Tamás,
There should _always_ be a Subject. A scheduled task or daemon
process should have a subject instance as well.
That is why the security world uses the term 'Subject' instead of
'User', since 'User' generally implies a human being. 'Subject' is
general in that it encompasses any state/identity information, be it a
human or daemon process or whatever...
On Mon, Dec 22, 2008 at 8:46 AM, Tamás Cservenák <[email protected]
<mailto:[email protected]>> wrote:
Hi there,
not directly related, but I have a question: all these solutions
assume you already have a Subject.
What about cases when it is not the case? (ie. scheduled tasks?)
~t~
On Thu, Dec 18, 2008 at 5:28 PM, Les Hazlewood
<[email protected] <mailto:[email protected]>> wrote:
Hi JSecurity community,
The JSecurity team will enable native support for the ability
to assume another user's identity at runtime, aka 'Run As' or
'Switch User' functionality into the framework very soon.
This allows the application to look, feel and react as if the
current user is another user entirely, a functionality that is
quite common in many applications.
We're looking to the community to get feedback on what people
prefer this be called in the API itself. Odds are very high
that the methods to perform this switching capability will
reside in the Subject interface (or a sub-interface of
Subject, we haven't decided yet).
So, here are a few alphabetically-ordered options that seem to
make sense (don't forget a 'principal' is just an identifying
attribute, like a username or user id). If you feel so
inclined, please choose one:
subject.assumeIdentity( Object principal );
subject.runAs( Object principal );
subject.switchUser( Object principal );
Please note that whatever the naming choice, the
implementation will retain raw traceability and auditing
attributed to the original or 'owning' user in all cases. You
won't 'lose' that when executing this soon-to-be-created method.
Thanks for any feedback!
Les
--
Thanks,
~t~
