On 3-Mar-06, at 6:28 AM, Robert Yates wrote:
Acme corp utilizes monster.com for its hiring process. Acme has a
site license for access to monster.com, however the agreement
limits acme to 10 concurrent users. To keep within this contraint
Acme limits the employees that can access monster.com. It utilizes
dmd0 and achieves this by having a user property called dix:/
monster.com/user-key. Employees that are allowed to use
monster.com have this property set.
An acme employee with the right to access monster.com goes to that
site's login page. Here, they type in their homesite
"intranet.acme.com", a homesite on acme's intranet. Monster.com
requests the attribute "dix:/monster.com/user-key" via DIX. The
user is bounced to their homesite, they authenticate and then they
get bounced back to the membersite monster.com with the property
set and the message signed.
The interesting aspect of the above scenario is that monster.com
cannot communicate with the server "intranet.acme.com" it is behind
the companies firewall. It is also worth mentioning that acme,
like all large multinationals, has "intranet.acme.com" locked away
deep inside a data center. It can talk to its ldap server and a
database server, but nothing else and certainly not "monster.com"
Correct. With dmd0 the enterprise would have to put its Homesite (HS)
endpoint out in the DMZ and punch a hole through the firewall so that
the HS code can talk to the enterprise IdM stack. It was a deliberate
compromise to simplify the implementation of a Membersite (MS).
It is in scenarios such as these that "push" excels. However in
the current draft the verification step is a "pull" step and so
dmd0 cannot support acme. Has there been any thoughts as to how
DIX can allow parties to sign the message without requiring the
"pull" verification step?
Yes... we've thought about this...
I could imagine specifying in core or in an extension attributes
such as dix:/signature-X509, dix:/signature-X509-subjectname and
dix:/signature-X509-certificate. Then monster and acme can relay
messages without any "pull" operation.
For sure digital signatures and certificates are a solution, but I'm
not sure I'd go about it in exactly that way.
John
What is preventing these extensions at the moment is the current
canonicalization algorithm and so I guess all of this was a very
long winded way of asking whether the canonicalization algorithm
described in section 5.10.2.7 can be changed to something like.
"For each name-value pair within the message, with the exception of
any parameters starting with "dix:/signature", treat as a ......... "
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
