Managing access to services in the Layer 7 SOA Gateway

In the Layer 7 SOA Gateway if you have several services and clients authenticating using SSL certificates then you may find the following helpful as I did.

The problem of maintaining access for dozens of clients authenticating with hundreds of client certificates to hundreds of services can be daunting if not approached with some degree of foresight.  Before I realized just how intense this problem could have been I was fortunate enough to experiment with policy fragments.  By placing our clients' certificates within fragments we could reference the fragment in the individual services, and not only was it easier to read in policy, but more importantly it was significantly easier to maintain in the long run.

With this convention, when we have to update one of our customers' client certificates we are able to upload the certificate and add it into the policy fragment which grants the new certificate access to all the services that their currently used certificate has access to.

Alternatively, you could upload the new certificate to the existing user, however this results in a hard cut-over to the new certificate.  By adding the new certificate to the fragment in parallel it maintains the access without having to touch all the individual services that they have access to and does not interrupt access for the older certificate that is currently in use.

Something to watch out for when adding the new certificate in parallel is that in older versions of the gateway (6.x-7.x) if a given Federated Identity Provider (FIP) contains two or more certificates with identical subject CNs then the authenticate user assertion cannot resolve either of them properly, which means that you can break access for the current certificate just by uploading the new certificate into the FIP.

One way to work around this issue is to validate the certificate of the incoming request by inspecting the certificate properties (${request.ssl.clientCertificate.thumbprintSHA1}), but remember the serial number and thumbprint from the request variables are 64-bit encoded but their properties are displayed in the interface (and in windows) in hex.

Another way to work around the duplicate certificate issue is to create another FIP with the same trusted root/intermediate authorities to house the new client certificate.  Personally I prefer to use the thumbprint work-around for three reasons; first it is less effort and therefor has less opportunity for error, secondly the thumbprint work-around can be removed when the older certificate is cleared out of the environment, and third is that in those versions of the gateway there is also an issue wherein if the subject CN of the certificate is longer than the field size of the mysql database column that contains the data then the this thumbprint inspection workaround also works to resolve.  When using this work-around remember to disable the authenticate user assertion(s) otherwise your policy will still produce an error.

If you choose to implement this convention then you can also use the following query against your database to audit which authentication fragments are referenced in which services; especially if you standardized the names of your fragments, which I highly recommend since the insert fragment reference pop-up lists all your fragments sorted only by name and not organized by folder (at the time of this post).  Note this query will include disabled fragment references.

SELECT s.objectid, s.name, s.routing_uri
FROM ssg.published_service s inner join
     ssg.policy_version v on (s.policy_oid = v.policy_oid and s.version = v.version)
WHERE v.xml like concat('%<L7p:PolicyGuid stringValue="',
                        (SELECT guid
                         FROM ssg.policy
                         WHERE policy_type = 'include_fragment'
                           AND name like ${fragment}),
   '"/>%')
ORDER BY s.name, s.routing_uri, s.objectid;