[Unicore-cvs-commits] SF.net SVN: unicore: [778] securityLib/trunk

[<go...@us...>]

Revision: 778
          http://svn.sourceforge.net/unicore/?rev=778&view=rev
Author:   golbi
Date:     2007-05-07 15:48:05 -0700 (Mon, 07 May 2007)

Log Message:
-----------
security lib: docs added

Added Paths:
-----------
    securityLib/trunk/docs/
    securityLib/trunk/docs/SecurityDraft.odt
    securityLib/trunk/docs/workplan.txt

Added: securityLib/trunk/docs/SecurityDraft.odt
===================================================================
(Binary files differ)


Property changes on: securityLib/trunk/docs/SecurityDraft.odt
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream

Added: securityLib/trunk/docs/workplan.txt
===================================================================
--- securityLib/trunk/docs/workplan.txt	                        (rev 0)
+++ securityLib/trunk/docs/workplan.txt	2007-05-07 22:48:05 UTC (rev 778)
@@ -0,0 +1,78 @@
+
+*** Main issues to address ***
+
+1) new style ETD (user can issue delegation to an agent)
+	- current ETD has limited usablity, agreement is generally achieved with Sven
+	- described in SecurityDraft
+
+2) request/response signing
+	- as it is generally neccessary for UNICORE6 final.
+
+3) user/endorser/consignor tokens in header clean up
+	- it's currently non sense, it is easy to be fixed. It is partially agreed with Sven.
+
+4) solve other issues
+
+*** Roadmap ***
+
+1) Library can be used to generate trust delegations, trust delegations chains
+and to verify both. There are two flavours of TD assertions: including or not including
+full certificate of TD Issuer.
+
+Usage to acheive backwards compatibility:
+ - old style ETD (assertions put in UUDB) can go with it - no need to modify anything
+ - if new-style ETD assertions are found in header then server has just an another
+ way to decide that Consignor is eligable to work on behalf of User
+ - new clients should generate ETD assertions, there will be need to retrieve certificates
+ of agents.
+
+
+2) At first we need to identify what message elements needs to be signed. 
+Proposition 1: 
+	SOAP Body element + 
+	all wsa: heder elements +
+	user SAML element if present (see SecurityDraft)
+Proposition 2: 
+	SOAP Body element +
+	all header elements that are put by client (i.e. Consignor)
+	
+Difference between propositions: the first one won't sign potential trust delegation tokens
+what is gennerally unnecessary, but 2nd is simplier
+
+Proposition is to add checking code to server
+that will only add extra security attribute 'signatureStatus' with possible values: 
+signatureOK|signatureWrong|signatureLack and a few security policies for UNICORE6 that will:
+	policyA) - do not worry about signatures at all except failed ones (but 
+	lack of signature is ok). This will allow to use currently existing clients.
+	policyB) - expect signatures for the most important operations (like
+	job submission)
+	policyC) - expect everything to be signed.
+
+
+3) It is quite simple:
+	- to achieve backwards compatibility the best is to hack gateway: 
+	it should accept both styles, but rewrite old-style tokens into new style tokens 
+	(it is possible). Then server can be only with one version.
+	
+	- 'endorser' is currently not used, and not defined in generic SecurityDraft.
+	It is not because it is not useful, but becouse it's usage depends on request body content
+	e.g. workflow language used (and how to endorse parts of this workflow).
+		-> this point can be controversial but we can leave it for further discussion.
+	So remove endorser checking/putting.
+	
+	- refactor format of the User token to SAML version. It will allow later to push
+	attributes (e.g. VO choice!). See SecurityDraft for details, library has support
+	for generating such tokens. Clients should put it. It is not signed so temporarly gateway
+	can convert old tokens.
+	
+	- client do not need to put 'consignor' token, gateway will add it by taking certificate from 
+	TLS. There is supporting code in library.
+	NOTE: gateway should check if there are no "consignor" tokens coming from client
+	and signed with it's certificate (e.g. somehow stolen).
+
+
+4) Currently there is no much of other issues:
+	- when to attach full certificates and when DN is enough in various SAML assertions?
+	- when to attach full certificate chains instead of just certificates?
+	- signing of server responses (likely analogical to client request signing).
+	


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.