| RE: [higgins-dev] Question about RP and STS trust |
|
Daniel,
We have implemented all
this in the ALF "Gatekeeper" RP which processes both
SOAP-based and
Browser-based requests and protects SPs behind it. It is part
of an WS-Federation
Passive Requestor Profile based SSO framework. The gatekeeper
is a security gateway
implemented as a Java filter on J2EE.
The approach we took is
very similiar to what you have descibed. We have a token policy
file
per each SP behind it
which describes the security policy for tokens used to authenticate
against
the SP. In it, we list
issuers that are "allowed" to issue tokens for each SP. We allow
the
admin to specify this
either by Issuer URL or Issuer Public Key or both (with Issuer URL
obviously
having the security
shortcomings you mention below. If a
trust relationship has been established
via PK, we compare the PK
from the token with the PK in the corresponding keystore file
described in the policy.
We do walk the certificate chain up when comparing. Keep in mind
that
the token does not
necessary contain X509 cert. For example Mike's tokens are signed and
contain
just the Public Key
(unless he changed that recently).
I do not like signing the
tokens with the SSL key. Also, your example of obtaining the Issuer's
public key via SSL
backchannel is a security risk - an attacker could pollute the RP's DNS
and
do a man-in-the-middle
attack thus spoofing you that token PK and the SSL PK are the same.
I also want to hear if
there is another way of establishing the trust. In our case, we
manually
export the Issuer's PK in
whatever format from the issuer's keystore and manually import it
in the PR's keystore
which is somewhat tedious process and if there is a way to improve
I'd
like to hear about it
too.
Regarding your
performance comments - in ALF SSO, for the browser-based requests,
we
use standard cookie to
store the STS-issued SAML token. These cookies are symmetrically
encrypted and compressed.
The key is known only to RP and is system-generated. Then we
SHA-1 it and keep a in
memory lookup table <k=(IP,hash),v=token>. If IP and Hash
match,
we assume the token is
golden and don't do the expensive policy matching. Granted, it can
be breached too - IP
spoofing isn't new but the chances of breaking the hash are pretty
small.
Additionally, a salt can
be introduced and each response can resalt the cookie making it
more secure.
In the case of SOAP-based
requests, we still do a full policy matching on each request.
For improving
performance, you could have implement WS-SecureConversation - you
expose
a local STS Endpoint in
your RP which authenticates the initial WS request the same way
you described below, and
then use a lighter token as described by WS-SC.
George
Stanchev
Sr. Software Developer /
Eclipse Commiter
Serena Software,
Inc. From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Daniel Sanders Sent: Friday, February 01, 2008 5:00 PM To: higgins-dev@xxxxxxxxxxx Subject: [higgins-dev] Question about RP and STS trust We have some questions about how an RP goes about establishing trust with
an STS. By "trust", we mean that an RP needs to be able to verify that a
token comes from an STS it trusts.
It seems to us that in order for an RP to verify that a token came from an
STS it trusts, it must do the following:
1. Verify the token signature against the token issuer's public key.
This should be the public key which is paired with the private key the
issuer uses to sign tokens. NOTE: It is assumed that the public key
is part of a certificate that belongs to the token issuer.
2. Verify that the subject ID in the token issuer's certificate is a
trusted subject ID. NOTE: The RP should NOT simply look at the issuer URL
that is attached to the token - it can be spoofed.
3. Verify that the token issuer's certificate was issued by a trusted
CA. Again, just because a certificate claims to be for a particular
subject ID does not mean it was actually issued by a trusted CA for that
subject ID. This too, can be spoofed - it is easy to do self-issued
certificates. The RP must verify the certificate chain back to a
trusted CA.
Steps 2 and 3 are onerous to do for every token received. First
of all, they imply that either a) every token has attached to
it a certificate that can be used to do steps 1, 2, and 3
above, or b) the RP has a way to obtain such certificates on the fly.
In SAML tokens there may be an associated <KeyInfo> element
that contains the certificate, but the performance implications make this a
distasteful solution.
It would be better if the RP already had the public keys of all
STS's it trusted and could do a quick table lookup to find the public key
for a given issuer URL. This implies that the RP gathers and validates, in
advance, all certificates for STSs it trusts. As it gathers
certificates, it would perform steps 2 and 3 above. Then, when the RP
receives a token from an STS, instead of having to perform steps 1, 2, and 3 for
every token, it only has to do a simple lookup on the issuer URL, find the
public key, and perform step 1.
The question we have is whether there is a generally agreed
upon "best practice" an RP could/should use to obtain and verify
certificates for STSs it desires to "trust."
If an STS's SSL private key is used to sign tokens, it would be easy for an
RP to get the STS's SSL certificate - there is a well established protocol for
doing so. However, using SSL certificates to sign tokens is generally
frowned on as a bad security practice, so we need an approach that does not
count on STSs using the SSL private key to sign tokens.
A somewhat clumsy approach we thought of would be for the RP to instruct an
administrator (via an administrative console or web pages) to obtain a
managed card from some STS the administrator wants to establish a
trust relationship with. Once the card is issued (and presumably saved to
disk in a .crd file) the administrator would upload the .crd file to the
RP, and the RP would extract the STS's signing certificate. This only
works if the administrator uploads a managed card that was actually issued
by the STS. To verify that the administrator did not make a mistake and
was not spoofed when he was issued the card, the RP would probably need to
present to the administrator details extracted from the certificate
and ask the administrator to verify that the certificate subject ID represents
the STS they are trying to establish a trust relationship with.
Does anyone have other ideas here? We don't want to implement this
admittedly clumsy mechanism only to find out that there are more standard
approaches that the industry widely accepts as the customary and normal way of
doing this.
Thanks,
Daniel Sanders
Daniel Sanders
Software Engineer dsanders@xxxxxxxxxx 801-861-4193  ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **********************************************************************
|