Re: [Nsi-wg] Issue 28 in ogf-nsi-project: Security
Comment #5 on issue 28 by thost...@gmail.com: Security http://code.google.com/p/ogf-nsi-project/issues/detail?id=28 I'd like to try and get SAML out of the WSDL before the SC11 demo. SAML is typically used in single sign on between identity provider and service providers. It does not really fit into NSI. We may have the need to have something like sessionSecurityAttr, though often these attributes are not related to security, but are typically request meta-data. Perhaps we could just call them sessionAttributes. Anyay I think the scheme with Name/Value in the protocol spec. e.g.: <sessionAttribute> <name> ... </name> <value> ... </value> </sessionAttribute> and a slighly more real example: <sessionAttribute> <name>requesterIdentity</name> <value>nsiuser@example.com</value> </sessionAttribute> The idea here is to have a place for connection information. What it should NOT be used for is any authentication or authorization, and ideally the attributs can be stripped without any reprocussions. If possible I would like to use this for SC11 visualization query tool, which could add something like: <sessionAttribute> <name>requesterIdentity</name> <value>NSIVisualizationTool</value> </sessionAttribute> Which would indicate to the NSI agent, that it should return all connections in the query made. This can of course be combined with proper authentication/authorization when we have that, but right we don't. Well there is the IP address, which can be made available from the MTL / protocol layer.
Comment #6 on issue 28 by jmacau...@gmail.com: Security http://code.google.com/p/ogf-nsi-project/issues/detail?id=28 The SAML AttributeStatementType was proposed to carry not only the information you have shown above, but also a person's public key, sign-on token, etc. This would allow for common externalized authentication and authorization systems such as Shibboleth. If we go back to the simple Attribute definition then we will not longer have this flexibility for networks that would like to propagate end user credentials. I am open for changing it, but we need to get feedback from people deploying NSI in their networks. I have attached the ESnet proposal that resulted in the inclusion of the SAML AttributeStatementType. Attachments: NISAA.doc 101 KB
Comment #7 on issue 28 by thost...@gmail.com: Security http://code.google.com/p/ogf-nsi-project/issues/detail?id=28 Hadn't seen that document before. In my opinion it misses one of the key points with NSI, i.e., that NSAs trust each other, and that a global user list isn't needed. When putting in signed requests into the message, an NSI infrastructure is essentially turned into a relay network. If a network provider does not trust other NSAs to make create connections, and requires proof of user identity, they should probably have users contact them directly and use something else than NSI. You can still propage end user identity (credentials are secrets, e.g., password or private keys, and are not intented for distribution), but the attributes can only be informative, not be used for authentication or authorization (not unlike the requesterNSA / providerNSA fields, and any other fields in the message).
Comment #8 on issue 28 by jmacau...@gmail.com: Security http://code.google.com/p/ogf-nsi-project/issues/detail?id=28 In the world of single sign-on this information is intended for distribution/sharing between federated identity providers. Have a look at Shibboleth https://wiki.shibboleth.net/confluence/display/SHIB2/UnderstandingShibboleth and the attributes shared between institutions across the world http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-...
Comment #9 on issue 28 by imo...@lbl.gov: Security http://code.google.com/p/ogf-nsi-project/issues/detail?id=28 - Security model should be separated from the messaging - A focused discussion on security needed - the chairs to organize that and invite the relevant security folks. -
Comment #10 on issue 28 by MaryRT...@gmail.com: Security http://code.google.com/p/ogf-nsi-project/issues/detail?id=28 The attached note was written to explain why SAML attributes for the originator of a connection request were added to the NSI schema. It is intended to be background information for a security discussion on the Nov. 2 phone call. It tries to clarify the usages of SAML attributes and points out the trust issues that are raised by their use as a basis for provider authorization. I think that the determining factor as to whether plain SAML attributes are useful, needed or insufficient is the authorization requirements of the operators that are providing the network resources. Attachments: SAMLinNIS.rtf 30.8 KB
participants (1)
-
ogf-nsi-project@googlecode.com