On Mon, 2008-01-21 at 15:52 +0100, Chad La Joie wrote:
Yes, when I made the comment about the VO needing an entity ID I was thinking that a VO would be represented by a distinct piece of software. Given my updated understanding that a single piece of software might represent multiple VOs, then yes, I think the VO attribute is needed. What does need an entity ID is the VO software system.
Thinking in VOMS terms, where service instances and VO have a one-to-one or many-to-one relationship, I liked the idea. But there's the need for having one-to-may relationships. If I understand correclty, Krzysztof were thinking about doing something like <saml:Attribute ... FriendlyName="vo" <saml:AttributeValue xsi:type="xsd:string"> aVo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> anotherVo </saml:AttributeValue> </saml:Attribute> If we go for that, on the line of the agreement on roles and groups, that a role scoped in a group must not be present if the group is not present , I guess the same must be done for groups. Groups hierarchically based in a VO must not be present is the vo is not present. Valerio
Valerio Venturi wrote:
Hi, I'll try to checkpoint the discussion had so far.
As Krzysztof is planning to serve more than one VO with the same service, we cannot have a one to one relationship between entityIDs and VOs, this imply the need of having a VO attribute. Which was also more or less David's concern, an authority being able to assert whatever it wants. If we go wiht this, the VO attribute stays. We have two proposal so far. Tom suggested to use the MACE-Dir eduPersonScopedAffiliation attribute
<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string" ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" FriendlyName="eduPersonScopedAffiliation"> <saml:AttributeValue xsi:type="xs:string">member@voName </saml:AttributeValue> </saml:Attribute>
while in our first draft Krzysztof and I suggested the use of a specific
<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="uri_to_define" FriendlyName="vo" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"> <saml:AttributeValue xsi:type="xsd:string"> voName </saml:AttributeValue> </saml:Attribute>
Let's try to agree on one.
There were concerns about Tom's proposal to use Grouper to express groups, specifically about the contents being an URN. Anyway, the specification doesn't mandate them to be URN, it recommends to use URIs is uniqueness is to eb achieved.
Other concerns with using this?
Still we have no suggestions for expressing roles, apart from the initial (but I have made the group syntax homogeneous with the above)
<saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="uri_to_define" FriendlyName="role" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"> <saml:AttributeValue xsi:type="xsd:string"> VO-Admin@vo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> SoftwareManager@vo:group:subgroup </saml:AttributeValue> </saml:Attribute>
that seems to receive more favor than the one with the scope attributes.
What problems can you see with that?
Valerio
-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg