Minutes from 4/24 WSRP Security Subgroup Telecon

 

Attendees:

Mark Cassidy, Jeff Broberg, Yossi Tamari, Alejandro Abdelnur, Bill Cox,  Adam Nolan, Mike Freedman, Rich Thompson, Greg Pavlik, Dave Clegg

 

 

Agenda:

1.  Discussion of end-user identity scenarios from Yossi’s document:

- End user is anonymous(1)

No issues or special requirements from a security perspective

 

- End user is identified(2)

There were several points of discussion and issues/questions that arose from this discussion:

a)  a user could either be explicitly be identified(such as with a userID, name, etc),  or some personal information could be passed which might make it possible to infer identify the user.   In the latter case, how to define what constitutes ‘personal’ information that might need to be protected?   Would a news preference be considered personal information if it was part of user profile data maintained by the portal, for example?

 

b) is there a need to support the notion of user profile in the protocol?  A related question is where is personalization data managed(by the portal or the portlet)?   If WSRP does support the concept of a profile, what standard data should be included?   General consensus was that if a standard profile is defined, support should be optional,  not required.

 

c) are users associated with portlet instances, i.e. would a userID and/or profile info be sent when a new portlet instance is created, such that subsequent runtime invocations would only pass the instance handle and not personal data?  This also ties into where personalization data is managed.  Does a portlet instance carry all the parameter data needed by the portlet to return markup to the consumer, or is some additional profile or user context information required?   In the latter case, where is the added information sourced from?

 

d) how do we represent userID in a standard, consistent fashion?

 

e) in this scenario, the portlet is trusting the portal’s authentication of the end user.

 

- End user is authenticated(3)

A couple key points in this discussion:

a) The key difference between this case (2) is that some type of credentials are passed from portal to portlet which might require additional protection.

 

b) The portal may or may not have authenticated the end user in this scenario.  If the portal did not authenticate the end-user, the portlet would use the provided credential to authenticate the end user.  If the portal did in fact authenticate the end user, credentials passed here may be unrelated to the authentication performed by the portal (perhaps a different/additional credential required for some back-end application).

 

c) MikeF raised the issue of whether we need to introduce the notion of authentication level(strong, weak, etc) employed by the portal, i.e. does the portlet need to know how the portal authenticated the end-user. 

 

- Credentials passed through intermediary(4)

In the case where an intermediary portlet is involved, the intermediary portlet would have a trust relationship with both the original producer that requires a credential, and the consumer portal.  In this case, the intermediary:

·        Would trust portal authentication of the end user

·        Would pass end-user identity and credential info along to original producer(s)

·        May or may not be able to see identity info about the end user

·        Would not be able to see credential info passed that belong to an original producer

 

 

2.  Discussion of new WS-Security spec

http://www-106.ibm.com/developerworks/webservices/library/ws-secure/

 

This new effort is being worked jointly between IBM, Microsoft, and Verisign, and is very applicable to WSRP.  In particular, it defines how user identity and security tokens can be passed in a SOAP envelope using <Security> elements which directly relates to the discussion in agenda item #1. 

 

RichT also said that there is a related effort(same working group?) to define policies for how to use the various security standards together as an integrated solution.

 
Both WS-Security and this related effort should therefore be considered a high priority for WSRP to be compatible with.

 

 

3.  Next Steps

- Draft of a formal document outlining scenarios & requirements.  Mark will try to have a starting point for this before next telecon.

 

- Begin to hash out questions above and those related to establishing/managing  trust relationship between portal/portlet in the discussion forum.