[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Security Considerations
All, this email followis on from my action to consider some of the security options that we have with respect to the Translation Web Service standard. Security Options There are four major options that we have, as far as I can see: 1. Do nothing 2. Pick a standard and specify its full adoption 3. Pick a standard and specify the adoption a small part of it 4. Specify our own security fuctionality 1. Do Nothing This option is by far the easiest. We would avoid making any references to any security standards, and leave that entirely up to service provider to specify what security architecture/standards/protocols that they provide. It would then be responsibility of the service client to implement the relevant functionality to comply with the security offered by the service provider. The advantage of this approach from a specification view point is that there is nothing to do - security becomes an implementation detail. A second advantage is that we don't tie the hands of those implementing the WS-Translation standard - they are free to choose the most appropriate level and type of security for their application. The disadvantage of this approach is that everybody will end up with a different security implementation, and hence, a client application of one service provider will not necessarily work with another service provider. It will be necessary to develop additional functionality to work with the security protocols of each additional service provider that a client wishes to communicate with. 2. Full Adoption of a Standard This option would involve picking an appropriate standard - probably either WS-Security or SAML - and mandating that an implementation of the WS-Translation also provides for a full implementation of the security standard. The advantage of this approach is that the specification is fairly straightforward. We examing the various standards that are available, and choose one that is closest to what we want to do, and mandate that this standard be implemented. A secondary advantage is that there would be one and only one security standard in play, and hence, a WS client for one service provider will work with all other service providers (assuming that they implement the security standard fully and correctly). The biggest disadvantage is that we are placing a significant burden on those implementing the WS-Translation standard. Not alone do they have to fully comply with WS-Translation, they also have to comply with a second stardard, and put the security architecture demanded by that standard in place. This may be overkill for the first version of the standard. 3. Partial Adoption of a Standard This option involves picking an appropriate standard - again either WS-Security or SAML - and specifying that a small and relevant part of that standard must be implemented by the service provider, and by the WS clients. For example, the following is an extract from the WS-Security standard that may be appropriate: <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext"> <wsse:UserNameToken> <wsse:Username>Joe</wsse:Username> <wsse:Password>password</wsse:Password> </wsse:UserNameToken> </wsse:Security> Here, the username & password are send in an XML fragment in the SOAP envelope. Since the password is send in plaintext, the SOAP converstation would have to take place over an encrypted connection - e.g. HTTPS. In addition to mandating the implementation of a partial security standard, we could also leave the door open for a more complete implementation of that standard, in the event that a service provider felt that it was necessary or appropriate. The advantage of this approach is that we would have some security in our specification, without over-burdening those implementing the standard. In addition, we would leave ourselves the option of including additional security measures in later versions of WS-Translation - moving over time towards option 2 above. The disadvantage of this approach is that the piece of the security standard that we choose will not be acceptable to all service providers, and hence, they may end up moving in different directions (as described in option 1 above), and hence, leading to incompatible implementations. 4. Specify our own Security The option would involve specifying whatever security options that we think are relevant for WS-Translation. It may involve ignoring, or at least not being bound by, existing standards out there, and going it alone. The advantage of this approach is that we can specify exactly what we want (e.g. authentication, authorisation, encryption, etc.), and ensure that it is implemented in a standard way. The disadvantage of the approach is that we would be ignoring work that has already been done in this area, and possibly by-passing other security infrastructure that a service provider or client may have. Summary In summary, and as a personal bias, I feel that we should: 1. Provide at least enough security specification to allow user authentication - that is validating that a user is who they say that they are 2. The implementation path for this authentication service should be fairly straightforward 3. We should leave the door open to implementors to expand on the security offered, in the event that their application or domain demands it. 4. We should leave the door open to ourselves to add additional security requirements in the specification at a later date. I feel that option 3 above best meets these goals. Whether the fragment of the WS-Security standard that I showed above is the right one to choose or not is another debate, but it does appear to meet the authentication requirements - albeit over HTTPS. Appendix There are (at least) two relevant standards in the security realm that we need to consider: 1. WS-Security: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss 2. SAML (Security Assertion Markup Language): http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security In addition, there is a new OASIS group Web Application Security: 3. WAS: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=was Of these, SAML appears to be the most active. However, additional research time will be required to identify which of these standards is most appropriate for our needs. --------------------------------------------- Stephen Flinter Connect Global Solutions [t] +353 (0)1 882 9038 [f] +353 (0)1 882 9050 [m] +353 87 798 1228 [e] stephen.flinter@connectcgs.com [w] www.connectcgs.com --------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]