simpleSSO

Thu Dec 22 16:18:03 EST 2016

Am 22.12.2016 um 15:22 schrieb Klingenstein, Nate <nklingenstein at calstate.edu <mailto:nklingenstein at calstate.edu>>:
> 
>> Both formats hold the implicit assumption that the claims that are of different provenance have been stitched together by the RA/CA respectively the federation operator. The RA/CA and FO are trust brokers, not finally authoritative. Although it is a convenient shortcut to think that the are.
> 
> To be honest, the deeper nuances in certificate authoristry are lost on me.  I wouldn't know how to take advantage of them, and I live by the convenient shortcut.  If you can think of a clever twist there that isn't confusing or hard, I'm eager to learn.

If you do away with ASN.1 and XML, the resulting data and trust models are quite comparable. I will show an example below.

> 
> Whether you call a CA or federation operator a trust broker or a final authority is a little fuzzy to me.  I get a signed metadata file or a signed certificate.  I have exactly one place to check if it's good.  Even in the MDQ model, I have to pick my single authority, from what I understand.

This is a loose description of an RP’s trust policy: "In CA/FO we trust" (and don’t bother me with the details how they became an authority). But to question the model we need to drill deeper.

>> To build a model of such a policy you need to decompose the current SAML federation structure, both PKI and SAML-MetaIOP,  extract the claims and its assertions, and build a graph where claims are nodes and the assertions are edges. At this point directed associations start to make sense. 
> 
> Maybe I'm not reading this right, but if I am, I'll need to think about this in more detail before it sinks in.  I usually treat claims(in the WS-Trust sense) and assertions(in the SAML sense) as pretty similar.  Could you please rephrase?

In this context I am using „claim“ for a subject-predicate-object triple like „Alice knows Bob“. An assertion is a verifiable statement by a trusted party, such as a signed XML infoset containing a number of claims.

Forgive me using abstractions and terms outside the usual contents of this list. Let me right this wrong with an example:-)

I will decompose an ordinary server certificate, such as that of www.tiimeworkshop.eu <http://www.tiimeworkshop.eu/> (very much recommended identity event, btw). Removing boilerplate and crypto-scaffolding, you end up with following attributes: 

Issuer, Validity (from/to), Subject, Public-Key and Certificate Policies

When I structure these attributes into triples I come up with this simplified list:

1. Issuer /is/ C=US, O=GeoTrust, Inc., CN=RapidSSL CA
2. Certificate /is-valid-between/  2012-02-06Z00:00:00 and 2017-02-05Z00:00:00
3. Subject /has-CN/ www.tiimeworkshop.eu <http://www.tiimeworkshop.eu/>
4. Subject /owns-private-key-of/ Public-Key
5. Public-Key /is-of-type/ RSA 2048
6. Public-Key /has-modulus/ 00:9c:18:c3...
7. Public-Key /has-exponent/ 65537
8. Issuer-CPS /published-at/ http://www.geotrust.com/resources/cps <http://www.geotrust.com/resources/cps>

Now you can label who is authoritative for each claim. The CA is authoritative for all claims except the subject-CN (with a domain-validated certificate it is the domain registrar) and the public key (it is the subject who create, proofs its possession and revokes). Therefore the CA brokers and aggregates trust.

The second example decomposes an EntitiesDescriptor with one SP-EntityDescriptor:

1. entityID /is-member-in/  metadata of XYZ-federation
2. entityID /is/ "https://sp77.example.org/sp.xml <https://sp77.example.org/sp.xml>"
3. entity-category /is/ some-attribute-bundle
4. entity /has-role/ SP
5. SP /has-property/ WantAssertionsSigned
6. SP /has-encryption-key/ <x509-cert ...>
7. SP /wants-NameIDFormat/ urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
8. SP /has-endpoint/ <md:AssertionConsumerService Binding="..." Location="..." index="0"/>
9. SP /is-operated-by/ <md:OrganizationName> ACME 

Endpoints, key material and contact persons will be determined by the SP. Who is authoritative for other claims will depend on the federation policy. claim #5 could depend on the SP, or on a mandatory implementation profile. The EntityCategory may depend on the SP’s type of organization or application function. Claim #1 is implicit by being included in an aggregate or MDX published at the federation’s metadata feed.

Again, as in the CA example, the FO is brokering assertions from other parties. 

The graph in the picture below shows the trust dependencies. This is not  1:1 to the previous list, because it is just a quick adoption from a project with a similar problem. I think that you get the idea. 

And, of course, having a (gated) public ledger for the triples would allow the generation of metadata and certificates by different parties based on different policies. Trusted brokers would still be needed to simplify metadata consumption by RPs.

- Rainer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161222/1cb4fb7a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: md-trust-rel.jpeg
Type: image/jpeg
Size: 35821 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20161222/1cb4fb7a/attachment-0001.jpeg>