AW: AW: AW: Programmatically get Assertion for 3rd party resources

[Brent Putman]

On 5/21/15 5:33 AM, Kevin Flückiger wrote:
>
>  
>
> I believe AWS in fact wants me to go the unsupported way since it is
> exactly documented like the unsupported way you describe. See:
> http://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingSAML.html
>

They are a little vague there about the exact requirements for the
Assertion to pass to their STS.

If what they want essentially can be the same Assertion that you get
via standard SAML 2 Web Browser Profile SSO:  It *might* be possible to
accomplish this with existing IdP code. Essentially you would have to
write an ECP client that did a SAML flow that started and stopped with
the ECP, as opposed to with the SP (via the PAOS binding, etc).  It
would essentially generate an artificial AuthnRequest as if it came
from the SP - sort of the ECP variant of "unsolicited SSO".  If you had
access to the user's credentials (username/password) this could be I
think a fairly simple ECP.

If instead you want the intermediary SP to obtain the new Assertion on
behalf of the user, using the SSO Assertion previously obtained as the
user credential, that may also be possible using the delegation/uPortal
support I earlier mentioned. Again the SAML flow would start and stop
with the ECP living on the intermediary/portal SP, which would execute
the Liberty SSOS call into the IdP as described in the uPortal wiki.

There may be some technical nits with SAML vis-a-vis this approach. But
perhaps no worse than what people have historically done for
"unsolicited" SSO by generating an unsigned AuthnRequest on behalf of
an SP and then delivering the unsolicited Response to the SP.

So if you're willing and able to write the ECP code, the IdP (+
optionally delegation extension) could probably support this.  Unless
I'm missing something important, which hopefully Scott will point out
to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150522/51779b7e/attachment.html>