Impersonation in IDP

[Greg Haverkamp]

>
> Thanks for the suggestion. In conf/c14n/subject-c14n.xml, it says this
> flow is used after authentication. I thought I could use this to switch
> user’s identity. I did some experiment and found this flow was executed
> after Remote user authentication, but before DUO. Is that the desired
> behavior? Is it possible to make this flow run after DUO? We currently use
> MFA flow.


What information is Adobe actually looking for? Can you do most/all of this
in the resolver, NameID machinery, and attribute filters, and just send
Adobe the appropriate account information?  You're not really trying to
delegate an "IdP account"; you're trying to delegate an account that relies
on the IdP.

Greg


On Thu, Aug 24, 2017 at 8:24 AM, Hong Ye <hy93 at cornell.edu> wrote:

> Scott,
>
> Thanks for the suggestion. In conf/c14n/subject-c14n.xml, it says this
> flow is used after authentication. I thought I could use this to switch
> user’s identity. I did some experiment and found this flow was executed
> after Remote user authentication, but before DUO. Is that the desired
> behavior? Is it possible to make this flow run after DUO? We currently use
> MFA flow.
>
> <!--
>     These are lists of Subject Canonicalization flows that turn complex
> Subject data into a string-based
>     principal name that the rest of the IdP can operate on. They're used
> both after authentication and
>     during operations like SAML attribute queries, to map the SAML Subject
> into a principal name.
>     Flows are identified with an ID that corresponds to a Spring Web Flow
> subflow name.
>     -->
>
> Thanks,
> Hong
>
> On 8/22/17, 5:08 PM, "users on behalf of Cantor, Scott" <
> users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:
>
>     > Here is the answer from our Adoble Sign admin regarding why user
> want to
>     > logon to Adobe Sign using shared account(departmental account):
>
>     I had assumed you meant Adobe Creative Cloud, I'm not familiar with
> that service.
>
>     I don't actually know how you got it to produce the error you did,
> which seems very unusual to me, but that's sort of the point.
>
>     This feature is something a lot of people want, and also something a
> lot of people are (rightly) terrified of, and there are a number of
> different places it could be injected. It has complex implications for SSO,
> for one thing.
>
>     I would strongly advise against anybody trying to do this inside a
> login flow. I'm pretty convinced it doesn't belong there and the complexity
> would be off the charts. I suspect it's really an interceptor that applies
> policy and then drops the attribute set and resolves a new one after the
> determination is made to switch the identity. That would confine it to a
> single transaction at a time and avoid polluting the SSO and session layer
> with really difficult questions.
>
>     -- Scott
>
>     --
>     To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170824/9a6c2c49/attachment-0001.html>