>> What your scheme does do is to enable enforcement of the audience >> restriction (service parameter), so that only the intended audience >> can even validate the ticket.
> Indeed, which seems more within reach than the HoK approach. Client certs used to authenticate the relying party to CAS are already in practice > as an alternative to the SSL callback. Of course that adds another set of certs to manage. Is this worth it to gain even more confidence in the audience > restriction for certain attributes? Actually, now that I look at it again, the second part of my email is not feasible (HoK for audience restriction), since there is no way to get the browser to do what I want the client to do: > 1) When the client ask for an ST, he presents the public key in the SSL cert presented by the service. I think that the first scheme is feasible if you want ST's and TGT's to be HoK tokens, but you are right that this is a different goal. Best, Bill > > What could be done to make the ST and TGT not be a bearer tokens is as > follows: > > 1) The client presents a client cert in the ssl/tls negotiation when > authenticating to CAS and indicates that he wants a HoK (holder of key) ST. > > 2) CAS authenticates the user and records their public key along > with the service attribute in the ticket registry with the ST and TGT. > > 3) The client presents his client cert in the ssl/tls negotiation > when sending the ST to the relying party (CAS client). > > 4) The relying party (CAS Client), presents the clients public key > as one of the parameters when calling serviceValidate/samlValidate. > > 5) CAS checks that the client's public key matches the one stored in > the ST during ST validation. > > 6) If the client presents a TGT to CAS to request an ST, the same > check can be done so that the TGT is also HoK. > > Basically this is just SAML-like HoK validation implemented in CAS. > Obviously it depend on the client possessing and using a client cert. > > Now you could take a similar approach to enforcing the audience restriction: > > 1) When the client ask for an ST, he presents the public key in the > SSL cert presented by the service. > > 2) CAS records this "service public key" in the ST. > > 3) When the service calls "serviceValidate", it must present a > client cert corresponding to the "service public key". > > This method would run into problems if there is any kind of "SSL" > proxying going (as happens with my company's outgoing proxy), or if > the target service is running in a cluster where SSL/TLS termination > happens at the node, since each node would be have different public/private key pair. > > These are all somewhat preliminary thoughts made up when pondering > SAML HoK tokens and then adapted to your audience restriction enforcement use case. > They could all be wrong... > > David Ohsie > ASD Arch. and Advanced Dev. > 410-929-2092 > > > > From: Andrew Petro [mailto:[email protected]] > Sent: Wednesday, March 20, 2013 11:32 AM > To: [email protected] > Subject: Re: [cas-user] Restricting access to SAMLValidate to > whitelisted sites and applications > > 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: > [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 > > -- > 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
smime.p7s
Description: S/MIME cryptographic signature
