[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Comments on "SAML Core Assertions, 0.2"
My comments reference document: draft-sstc-core-vmodel-examples-01.pdf (1) Ticket Example (1.1.2) Defining a fixed size "small" ticket aka "assertion reference". (a) Assertion_ID: This appears to be a combination of a ticket issuer id and an assertion number. I do not see how 7 bytes are enough to represent BOTH the ticket issuer and the assertion number. While an IP quartet may be enough to identify the ticket issuer (BTW, I would avoid identifying this with the actual address of the AP server), it seems to me 8 bytes (64-bit number) would be minimally required to represent assertion numbers. There is no need to call out a specific format for the assertion number BUT we do need enough space so that APs can create a unique assertions over large time periods. (b) Account: This one really caused me some real difficulty. Is this a resolved "name" of the subject? At its simplest I would imagine this as a pair of strings ("alice" X "finance"). In many common cases, it could take the form of a X.509DN (cn=alice,ou=finance,co=...) or some kind of one time string token (surely at least 8-10 bytes?). IMHO, Most "reasonable" schemes will require a fairly large size representation. The question arises why such a "name" is required in addition to an assertion_ID? Is the main issue to ensure that the ticket itself be a complete assertion about a subject(mid-page,p.7)? (c) Authentication: I would question the need for a mandatory signature here. The assertion itself is provided separately over some mutually authenticated channel between the AP and RP. Why is there a need for a signed ticket as well? What is the threat model here? 2. Assertion (1.1.5) My main comment here is that it is extremely unlikely that BizEx Hub will maintain AuthZ information about SPECIFIC resources at Carol's store (e.g., http://store.carol.test/finance) unless both entities belong to the same security domain. This comment is also relevant to the example on the bottom of p.7. Basically, the issue here is that Carol manages her AuthZ INDEPENDENT of specific AuthZ APs (sites providing authenticated users). In the use-case where BizEx and Carol belong to distinct security domains, the BizEx hub will authenticate Alice and issue some type of AuthZ information defined by the business relationship between Carol and BizEx. I guess the URN rights identifier would cover this case; alternatively (and more likely) Carol and BizEx will agree upon some specific AuthZ XML schema to represent these rights. Following, thru this analysis I have one final issue: the AuthZ decision at Carols site is based on the assertion issued at the BizEx site. Let us assume that Carol utilizes a PEP ---> PDP type of AuthZ decision engine. In such a case, the PEP --> PDP protocol may need to include assertions originating from various different sources (BizEx exchange, SomeOther exchange, ...) in determining whether a subject is permitted access to a resource. This is one of the core pieces of the S2ML Authorization service protocol and some equivalent would be required within this design as well. - prateek
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC