The feature depends on what mechanism you authenticate.
If you use JAAS (and Subject as the security context), then you can use
the JDK Subject.doAs() call (David's email below).
But if you are allergic to JAAS like most modern developers are, then it
is a different story.
In addition to impersonation, the other feature is step-up/step-down
authentication in terms of roles getting added to/removed
for certain operations.
On 05/03/2013 10:20 AM, Pete Muir wrote:
Yeah, this was part of Core, not IDM.
On 3 May 2013, at 16:19, "David M. Lloyd"<david.lloyd(a)redhat.com>
wrote:
> >The (theoretically) "right" way to do this in the JDK is to
authenticate
> >a Subject and use Subject.doAs().
> >
> >That first authentication part is really the interesting part though.
> >There are two main ways to do it:
> >
> >1. Establish that certain Subjects have permission to run as certain
> >other Subjects implicitly, thus the original authenticated Subject is
> >essentially the only credential you need.
> >2. Perform another authentication process (maybe prompt the user for the
> >target user's password for example).
> >
> >The right option depends on the right circumstances, but this (if
> >nothing else) is a use case that the JAAS authentication API is actually
> >sufficient for. In particular I think IDM is a secondary player in this
> >kind of thing.
> >
> >On 05/03/2013 09:50 AM, Pete Muir wrote:
>> >>This was on the original requirements list, IDK if it's implemented
in this version or is scheduled for a later release.
>> >>
>> >>On 2 May 2013, at 17:19, Pedro Igor Silva<psilva(a)redhat.com>
wrote:
>> >>
>>> >>>+1. "RunAs" feature ...
>>> >>>
>>> >>>----- Original Message -----
>>> >>>From: "Rodney Russ"<rruss(a)redhat.com>
>>> >>>To: "Anil Arora"<anil(a)yieldex.com>
>>> >>>Cc:security-dev@lists.jboss.org
>>> >>>Sent: Thursday, May 2, 2013 1:13:08 PM
>>> >>>Subject: Re: [security-dev] Impersonation feature (was:
Quickstarts)
>>> >>>
>>> >>>I have seen the need for a feature like this when a customer
support representative needs to order on behalf on someone. In this particular case, the
customer support rep could only order on behalf of the customers they were responsible
for, but did not need credentials to "become" the users they were supporting.
>>> >>>
>>> >>>-Rodney
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>To add to the list, I don't know if there's a feature for
this...
>>> >>>
>>> >>>But, is there a way to do impersonation of users? Essentially,
one user/agent logs in and then becomes a different user without requiring the user
password. We're seeing this for REST based server-to-server communication calls. I am
extrapolating that I could do some sort of silentAuthentication like indicated in the doc
on the TicketMonster-PicketLink example, but that piece of the code isn't visible on
the product documentation page.
>>> >>>
>>> >>>Thanks,
>>> >>>Anil
>>> >>>
>>> >>>
>>> >>>On Apr 30, 2013, at 4:59 PM, Shane Bryzak wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>There's three quickstarts that have been merged into JDF so
far:
>>> >>>
>>> >>>picketlink-authentication-jsf - Simple authentication example
>>> >>>picketlink-authentication-idm-jsf - Authentication using Identity
Management
>>> >>>picketlink-authorization-idm-jpa - Authorization example based on
groups and roles
>>> >>>
>>> >>>You can find these in the JDF repo here:
>>> >>>
>>> >>>https://github.com/jboss-jdf/jboss-as-quickstart
>>> >>>
>>> >>>There are also a whole bunch more planned and in progress, which
we'll be adding as they are completed. If you have a good idea for a quickstart,
please let us know also.
>>> >>>
>>> >>>Shane
>>> >>>
>>> >>>
>>> >>>On 01/05/13 08:35, Anil Arora wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>>Is there a location for the quickstarts? I've seen
references in the emails and on the Wiki roadmap, but I've not seen any discussion
about that.
>>> >>>We're definitely anxious to see how we can utilize PicketLink
3 for our prototypes, including preliminary OAuth 2 support.
>>> >>>
>>> >>>Thanks,
>>> >>>Anil