...
- Equivalent functionality is currently available with CoSign and Stanford's WebAuth.
- Consequently, the issues and approaches are already known, but complex.
- Because of how kerberos is typically deployed, this approach is probably only relevant to intra-domain situations.
- Use Shibboleth to transport a Kerberos ticket to SP-A as an attribute; SP-A then presents the ticket to the backend service.
- No constraints on the protocol stacks SP-A uses to communicate with the backend.
- This approach relies on KeberosKerberos' existing support for delegation; the ticket must already be a "delegated ticket". .
SOAP
- Typically described as used by a portal/mid-tier to access backend services.
- Security typically described as using WS-Security and WS-Trust, etc.
- The client (in the mid-tier) and the server (backend) applications would typically use a framework (WCF, Axis, etc) to compose and process SOAP messages.
- Consequently, these frameworks would have to support the use of SAML credentials within WS*, as well as the use of delegated credentials. The problem is that no one is using a SOAP framework that we can easily integrate with.
- There's also a belief that applications aren't really using SOAP between tiers. There's discussion of using SOAP to integrate components of large administrative applications; its hard to find real examples of using SOAP + Security with academic and collaborative applications.
- Describe the EGEE/SWITCH strategy.
- There's a suggestion to extend the 2.0 IdP to support requesting credentials via a SOAP connection. The belief is that this won't be used by anyone, adding support tot he claim that SOAP isn't really being used.
Liberty Protocols
- Not geting sufficient traction in the marketplace for us to even consider using these protocols.
CardSpace
- Tooling packages readily available for processing messages.
- WS-Trust, etc already support the forwarding and processing of delegated credentials.
- Shib's CS support would have to support the use of holder-of-key.