A try to clarify some issues raised in this thread generally, and then I get down to some ideas for addressing Michael's requirements specifically:
Service tickets are bearer tokens authenticating the end user. They do not authenticate services, applications, or anyone else. These bearer tokens are borne by the end user and by the application the end user presents them to attempting to log in to it. When you configure CAS to release attributes in exchange for a service ticket, then you are configuring CAS to release attributes in exchange for a token that authenticates only the end user. If the bearer of a bearer token is compromised by the Adversary, then the Adversary gains access to the borne tokens and, because they are bearer tokens, can make use of them with impunity. So, here, if the user agent is hacked, the Adversary can lay hands on the service tickets the user acquires (or capture the user's password and then acquire any other service tickets he likes) and can take those service tickets and validate them himself, harvesting all the user attributes they yield. This is not a security defect in CAS as such. It's just the nature of the security model, of the design. Service tickers are bearer tokens. They have these characteristics. CAS adopters should configure CAS to release only user attributes that they are willing to release under this security model (or enhance CAS to change the security model). That is, only release attributes you're willing to release to the end user's user agent, which, sure, like all things in life, might be compromised. Or the end user might have given up his password in a phishing attack. Or shared it with his significant other with whom he's now had a nasty breakup. You get the idea. End user authentication is a horribly messy thing, and service tickets are only obtained by end user authentication, not by authentication of anything else. Bearer tokens authenticating the end user. Proxy Granting Tickets have different security properties. A service must authenticate itself (via an https callback mechanism) to obtain a PGT, and a PGT authenticates that service in the context of its participation in the end user's single sign-on session. So. If you want to add authentication of the service doing the ticket validation, that's a fine thing to add. I see it as on this roadmap: https://wiki.jasig.org/x/OwE_Aw and it would simplify aspects of CAS. The PGT callback would be unnecessary, since the PGT could be included directly in the validation response. ClearPass would be unnecessary, since the password could be included directly as an attribute in the validation response. It's a fine improvement to make. It amounts to making service tickets no longer bearer tokens and instead tokens that only the intended relying party can successfully validate. So then there's the question of how to authenticate these services, these relying parties. Shared secret, with the shared secrets registered in the service registry, feels like the Simplest Thing That Could Possibly Work. If I were coding a proof of concept of this, I'd start there. TLS has potential. Shibboleth in principle can handle this by encrypting the SAML assertion with the relying party's public key so that only the holder of the private key, the relying party, can decrypt it. If my initial use cases for services needing to obtain attributes JIT that ought not to be released to end users were narrow enough, I might start there, introducing a Shibboleth IdP for use with my CAS server and preferring it as the feature-rich engine for attribute marshalling, transformation, and JIT release via encryted SAML assertions. I should immediately temper the enthusiasm of the signed SAML assertions idea, though, with the recognition that encrypting SAML assertions is not widely adopted and my impression is it's not supported as widely as would be desirable. Still, it's a formal and rigorous way to accomplish this. I'd also say this: you could invent a new, ClearPass-like CAS server endpoint, say /cas/attributes and require applications to present a proxy ticket to authenticate to that, just as today they present a proxy ticket to authenticate to ClearPass. The implementation of that endpoint would need to know how to translate from the authenticated proxy chain to the set of services you'd like to release, but a naive implementation of treating the last identifier in the proxy chain as a service identifier and doing the service registry lookup might well be good enough. This would get you to a security model where the token is authenticating the relying party in the context of the end user's SSO session rather than just the end user, without inventing any new shared secrets, TLS reliances, or public key cryptography, and instead leveraging the n-tier authentication feature already in CAS. Hope this helps. I do think it wil be worth getting to an updated CAS product, protocol that does authenticate services doing ticket validation, because while I don't think the current model is broken -- it's entirely serviceable for what it does -- I do think a security model where service tickets are not merely bearer tokens will be even better. Andrew PS: The requirement on the validation call from relying parties to CAS (the call where they validate a service ticket, as in a call to /samlValidate) requires presentation of the correct Service identifier to which the service ticket was intended to authenticate the user *not* because an Adversary would have any difficulty guessing a correct value for this parameter, but only to help relying parties not fall prey to illicit proxies. An illicit proxy would arise if end user A obtains service ticket to authenticate to application B, presents the ST to B, and instead of validating the ST, B presents the service ticket to C to attempt to illicitly log in to C as the end user. C will attempt to validate the service ticket and the validation will fail because C will use its own identifier as the service parameter on the validation attempt. Not because it couldn't have used any other parameter or because it couldn't have guessed the one matching the service ticket (the namespace is in practice way too small to make guessing difficult), but because that's not the question it asks. Presenting the service parameter is in effect asking CAS "Hey CAS, whom if anyone does this ST authenticate to this service?" CAS could just as well have included the service identifier associated with the ST in the validation response, except relying parties might not properly validate that, just as they sometimes overlook the need to validate proxy chains. On Tue, Mar 19, 2013 at 5:32 PM, Michael Easthope < [email protected]> wrote: > That's basically it. Remember that the redirect is a request being sent to > the users device. If they are running a malicious app then the app can > choose not to honor that request. > > At that point, the app has all the information it needs to generate a > samlValidate call. There can be SSL between the original site and the > device; and between the device and the cas server - but on the device > itself the information is not protected. > > The service registry doesn't help because from the point of view of the > cas server, everything looks normal. > On 20 Mar 2013 03:23, "Andrew Morgan" <[email protected]> wrote: > >> On Tue, 19 Mar 2013, Michael Easthope wrote: >> >> Its an edge case but if you can trick a user into logging in AND you >>> control the http flow (eg if you are running a malicious mobile >>> application >>> that pretends to be a legitimate app) you can intercept the redirect URL >>> that comes back from a successful sign-in. That redirect URL contains >>> both >>> the service URL and the service ticket - with that you can generate a >>> samlValidate request and obtain the user details - something we only want >>> to be releasing to our own applications. >>> >> >> Let's see if I understand: >> >> 1. User goes to https://yoursite >> 2. User is redirected to CAS for login >> 3. User authenticates and is redirected back to https://yoursite >> 4. Something executes a Man-In-The-Middle attack to change the redirect >> to https://badsite? >> >> That doesn't make sense because SSL should be preventing MITM attacks. >> >> Or are you saying there is a mobile application (not a browser) that is >> talking to https://yoursite? >> >> Wouldn't the CAS Services Registry matching rules allow you to specify >> which sites are allowed? Or are we talking about a proxying situation? >> >> Andy >> >> -- >> You are currently subscribed to [email protected] as: >> Michael.Easthope+jasig@gmail.**com <michael.easthope%[email protected]> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/**display/JSG/cas-user<http://www.ja-sig.org/wiki/display/JSG/cas-user> >> > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
