<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">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.</span></blockquote><div><br></div><div>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.</div><div><br></div><div>Greg</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 8:24 AM, Hong Ye <span dir="ltr"><<a href="mailto:hy93@cornell.edu" target="_blank">hy93@cornell.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Scott,<br>
<br>
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.<br>
<br>
<!--<br>
These are lists of Subject Canonicalization flows that turn complex Subject data into a string-based<br>
principal name that the rest of the IdP can operate on. They're used both after authentication and<br>
during operations like SAML attribute queries, to map the SAML Subject into a principal name.<br>
Flows are identified with an ID that corresponds to a Spring Web Flow subflow name.<br>
--><br>
<br>
Thanks,<br>
Hong<br>
<div class="HOEnZb"><div class="h5"><br>
On 8/22/17, 5:08 PM, "users on behalf of Cantor, Scott" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br>
<br>
> Here is the answer from our Adoble Sign admin regarding why user want to<br>
> logon to Adobe Sign using shared account(departmental account):<br>
<br>
I had assumed you meant Adobe Creative Cloud, I'm not familiar with that service.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a></div></div></blockquote></div><br></div>