SAML?

[copumpkin]

It seems like the hologram server is playing the part of a simplified SAML identity provider, and the client could be taking SAML assertions from such a provider and calling AssumeRoleWithSAML directly.

I'm wondering if the AdRoll team considered using that approach and what the downsides might be.

[walterking]

Honestly, we didnt know what saml was when we built it, and still find the iam docs confusing on what mechanism is best. It was also brought up here: #39.

We have a saml server now, shibboleth, and could see using that, though I've found it a difficult piece of software to use and configure. One of the hold backs on merging the role support ticket was I wanted to make sure we could unify that with how saml worked so you get the same role from either system. We would still need an authentication mechanism - client ssl seems like the obvious one, since we don't want to have to type a password in every time and i think its already supported.

But on the other hand, simple is good, and provides a redundant mechanism for logging in.

[copumpkin]

Makes sense, thanks. I think ultimately what I'm looking for is a more pluggable Hologram agent to experiment with alternate designs. Given this SAML thing, I now have at least three use cases beyond the original Hologram for an agent that pretends to be EC2 metadata and serves up AssumeRole credentials for me. I might start experimenting with refactoring the Hologram agent so that it can still support your original protocol, but also gives me what I need.

[Krylon360]

you could use Kerberos / NTLM Auth. I've forked the kerb-sts project (Python) and made some enhancements to it for my work; which allows developers to Dynamicly generate keys; once they Auth with our ADFS server. The Keys are generated using AssumeRoleWithSAML, along with validating they have permissions (AD Group -> AWS Role with a Trusted idP Our ADFS Server) With Kerberos; it uses the Cached Kerberos Ticket that is created with they log into their machine.