Carl, > I guess a "rogue service" that was registered with the server that could > somehow steal STs from a neighbor service could gain access to attributes > that only the neighbor could see.
Services impersonating users at other services with a replayed ticket/assertion was precisely the reason for this in SAML. It was a big consideration for inter-organizational use. http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf In general, I prefer the “don’t make them ask for permission; make them beg for forgiveness” model, but there is data that even remediation and lawsuits couldn’t claw back. All of this is not really a consideration as long as interoperation isn’t a consideration, and it's a much smaller concern for the typical CAS use cases. This came up most recently when thinking through how stateless you *could* make a CAS server. I could stuff whatever I want into a ticket as long as I understand it when it’s played back to me because it’s just an opaque string to the rest of the universe. The length limitations will bite pretty quickly, but all this *could* get serialized and farmed out. There’s just no standard way to do so. It’s not a security concern at that point: it’s a data replication problem. It’s just a question of where the data used for those checks lives. But that’s even harder than security. Thanks, Nate. -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
