5965 2008-03-30 19:48 implement SAMLPrincipal class in GS-ST 2008-06-23 07:52:09 1 1 1 Unclassified GridShib SAML/Binding Tools 0.4.2 All All RESOLVED FIXED P3 normal beta 5960 6176 5791 6179 6332 1 trscavo@gmail.com trscavo@gmail.com gridshib-dev@globus.org tfreeman@mcs.anl.gov vwelch@uiuc.edu trscavo@gmail.com 2008-03-30 19:48:27 Implement a new SAMLPrincipal class and incorporate it into GridShib Common. See Bug 5960 for a precise list of requirements. trscavo@gmail.com 2008-06-20 09:38:57 The following tasks have been completed: - implement class SAMLPrincipal and its unit test: org.globus.gridshib.security.saml.SAMLPrincipal org.globus.gridshib.security.saml.SAMLPrincipalTest - implement method getSAMLPrincipals in SAMLSecurityContext: public Principal[] getSAMLPrincipals(); - rewrite toString(boolean) method in SAMLSecurityContext; in particular, add SAML principals to string representation of SAMLSecurityContext - log SAML principals in SecurityContextLogger - expose method quote(String) in SecurityContextLogger: public static String quote(String value); trscavo@gmail.com 2008-06-20 10:05:23 The security context must maintain the following invariant: For every *trusted* SAMLIdentity (whose NameQualifier is null), there is a corresponding SAMLPrincipal (and vice versa). That is, there is a one-to-one correspondence between SAML principals and trusted, unqualified SAML identities. I haven't figured out how to maintain this invariant in GS-ST. In GS4GT, there is a hack in AttributeAcceptancePIPImpl that instantiates a SAMLPrincipal for every SAMLIdentity that meets the requirements. Of course that won't work in GS-ST (which has no notion of "interceptor"), and besides, it's error prone to have to maintain the invariant manually. I'm considering my options. Comments welcome. trscavo@gmail.com 2008-06-20 15:07:11 (In reply to comment #2) > The security context must maintain the following invariant: > > For every *trusted* SAMLIdentity (whose NameQualifier is null), there is a > corresponding SAMLPrincipal (and vice versa). That is, there is a one-to-one > correspondence between SAML principals and trusted, unqualified SAML > identities. To maintain this invariant automatically (i.e., without developer intervention), the trick is to nest a SAMLPrincipal object inside each SAMLIdentity instance. Initially, the nested SAMLPrincipal object is null, but when the setTrusted(boolean) method on the SAMLIdentity instance is called, a SAMLPrincipal object is created if the conditions are met. trscavo@gmail.com 2008-06-20 15:16:42 Committed the following source files to CVS HEAD: org.globus.gridshib.security.saml.SAMLPrincipal org.globus.gridshib.security.saml.SAMLPrincipalTest org.globus.gridshib.security.SAMLIdentity org.globus.gridshib.security.SAMLIdentityTest trscavo@gmail.com 2008-06-20 15:48:41 Added getSAMLPrincipals() method to SAMLSecurityContext. Modified the toString(boolean) so that it includes SAML principals. If verbose, the toString method also returns string representations of other principals and the X.509 certificate chain. (It already returns the raw SAML assertion if verbose.) Log SAML principals in SecurityContextLogger. Made the quote(String) method public (so I can use it in the GS4GT security context). trscavo@gmail.com 2008-06-20 15:58:43 I'll note for the record that the current implementation of SAMLSecurityContext prevents duplicate security items from being added to the security context. This is a natural consequence of the Java Collections API and the equals methods of the SAMLIdentity, SAMLAuthnContext, and BasicAttribute classes. This will be important in the next iteration of GS4GT. trscavo@gmail.com 2008-06-20 16:03:02 In addition to the files in Comment #4, the following source files have been committed to CVS HEAD: org.globus.gridshib.security.SAMLSecurityContext org.globus.gridshib.security.SecurityContextLogger This completes the integration of SAMLPrincipal into the GridShib Security Framework. This new feature will be available in GS-ST v0.4.3.