Minutes from 4/3 WSRP Security Subgroup Telecon

Attendees: Mark Cassidy, Jeff Broberg, Greg Pavlik, Rich Thompson, Alejandro Abdelnur, Petr Palas, Michael Freedman, Yossi Tamari, Thomas Schaeck, Carsten Leue, Dave Clegg

Agenda item #1. High level scenario discussion:

- Initial comment from JeffB: should we focus on the existing Embedded use case? Concerned about proliferation of scenarios; consensus was to stick with security-centric use cases until requirements are more clearly understood. It may make sense then to combine security into one of the other primary use cases.

- MarkC did brief walk-through of the high-level scenario document.

Comments:

- WSRP services may employ techniques for document encryption, secure transport, digital signing, etc. May need to include information in the service metadata on which are employed by the remote portlet. Also a possibility that an upcoming WSDL rev may provide this support(RichT)

- SOAP differences between MS, IBM need to be considered to avoid using techniques that will only work on one vendor’s platform(ThomasS)

- WSIA & WSRP share common security issues. Embedded use case document from WSIA lists numerous standards efforts currently active in the security arena.(RichT)

Several proposed focus points emerged from discussions:

Portal identity, establishment of trust between portal and portlet; Thomas offered a lifecycle metaphor:

- establishment of trust relationship at initial service bind

- use of credentials established above for service requests

- removal of trust relationship when service is revoked

Questions to answer under this point include:

What types of credentials need to be supported/exchanged between portal and portlet?

How are credentials passed in a service request?

What are potential approaches for establishing and revoking trust?

End user identity: Yossi offered three different cases:

- Anonymous: no end-user info is passed to the portlet

- Identified: some identity and possibly other attribute information about the end user is passed to the portlet.

- Authenticated: some credential about the end user is passed to the portlet

Alejandro commented that the mechanism for passing end user identity/attributes to the portlet should be part of the scope of this sub-group’s effort.

Questions to answer here include:

How is end-user identity info passed from portal to portlet?

What types of end-user credentials need to be supported?

What are the possible ways for passing end-user credentials?

Secure Transmission: This deals with protecting sensitive data during transmission between portal and portlet.

- document-level encryption

- transport-level encryption

Questions here include:

Which current standards efforts deal with document-level encryption? Which should we focus on for WSRP as a concrete approach?

What about secure transport? There is SSL for http; since we shouldn’t be specifying a transport however, are there other secure transport standards? Is there a mechanism to secure the envelope without secure transport underlying?(MikeF comment)

Preventing Impersonation:

How to secure against an impersonator from obtaining sensitive data or obtaining unauthorized service.

- digital signatures could fall under this topic

- this might overlap with one or several of the above.

Questions here include:

- What standards for digitally signing documents should be considered?

Agenda item #2: Additional Scenarios

Since we didn’t have any input from a content provider’s perspective, we wanted to specifically solicit feedback from the following people:

- Bob Serr, Nigel Ratcliffe, and Mark Rosenberg: we’d like scenario input from your companies’ perspectives focusing on the points a-d above.

Comment from Dave Clegg: another possible scenario: nesting/embedded; if there are other intermediaries in the path between portal a portlet, may not want to expose end-user information to the intermediaries; do we need a mechanism to keep end-user data secure through middle tier services?

Agenda item #3: Actions, Next steps

1. RichT will update Embedded document with status of related standards efforts and summarize in next meeting.

2. MarkC to integrate the various issues/views into an organized set of discussion topics to focus on(initial cut at this captured in a-d above, culled from meeting notes).

3. Scenario inputs from Bob/Nigel/Mark

4. Thomas to provide additional scenario input related to (a) above

5. Yossi to provide scenario input to (b) above

Editor’s note: Prior to the next meeting, I’d like to have feedback/mail discussion on whether a-d above is a reasonable way to look at the issues in the scope of this working group. If we can agree to use this or something close as our starting point, I’ll update the scenario doc that I started prior to the meeting to reflect these focal points. The agenda for the next meeting then would be to review additional scenario inputs from those named above, and begin working through the questions related to each focal point.

Minutes from 4/10 WSRP Security Subgroup Telecon

Attendees:

Mark Cassidy, Jeff Broberg, Thomas Schaeck, Yossi Tamari, Alejandro Abdelnur, Bill Cox, Bob Serr, Adam Nolan, Mike Freedman, Rich Thompson, Carsten Leue

Agenda:

1. Feedback around proposed focal points for this group:

- portal identity, trust relationship between portal and portlet

- end user identity, profile, and credentials

- secure transmission of data

No significant issues raised on the above points. BobS raised the question of whether we should include access control functionality as part of WSRP scope. For example, if a portlet implements differentiated levels of access based on some user attributes, does the portal need to enforce these? Consensus from this discussion was that it shouldn’t be required that the portal enforce access control on behalf of portlets, but it may make sense to provide a mechanism for the portal to pass assertions about the user to the portlet so it may apply it’s own access control logic to the request. This will be captured under the ‘end user identity’-related requirements.

BobS also asserted that as a general philosophy, as little as possible should be communicated between portal and portlet about the end-user. Yossi: portlet should define end user data it requires as part of its metadata. MikeF: should have good defaults for this. RichT: portal is where any user privacy preferences(ala P3P) need to be enforced.

MikeF brought up the issue of replay attacks and a need to support safeguard mechanisms. Thomas raised the point that secure transport provides some protection here, and that we should consider constraining our focus on SSL. Rich argued that xml encryption is also an important element in prevention of replay attacks, and that we shouldn’t drop that as solution that should be possible with WSRP. Carsten raised the issue that SSL interoperability across j2ee/.net/… platforms is good, and SSL can be declared in UDDI, while there are concerns about interoperability of xml document encryption mechanisms.

2. Related Standards efforts: we walked through the standards efforts outlined in the WSIA Embedded document and identified the most relevant to focus on in the WSRP context. Highest priority is to focus on the following as relevant to WSRP:

- XML Signature(W3C/IETF)

- XML Encryption(W3C)

- SAML(OASIS)

The specs in these areas need to be analyzed for use with WSRP as a means to address requirements in each of the focus areas of this working group. BobS pointed out that use of any of these mechanisms should not be required by portlets but that they should be optional. Thomas further emphasized this with the point that implementing digital signatures for end-users can be quite complex, requiring an end-user-client mechanism such as a smart card or other technique.

3. Trust relationshship flow: Thomas walked through a conceptual flow for establishing & revoking trust between portal and portlet. Discussion around initial step of setting up business relationship transaction with service provider. Metadata may describe that a credential is required which would likely be obtained by the portal outside of WSRP prior to initial service bind. MikeF raised question of whether there is a scenario where credential would be delivered programmatically to the portal at bind time. Conclusion was that WSRP protocol should deal with returning a bind ID(in effect for the life of the trust relationship). Trust relationship isn’t required between portal and portlet, but when one is needed, the portal would obtain its credential outside of WSRP.

It was also noted that passing credentials in conjunction with a service request subsequent to initial service bind does not need to involve WSRP protocol. For example, a client certificate used to obtain a secure transport connection between portal and portlet would be passed outside of the WSRP protocol.

4. User identity scenarios: Walkthrough of Yossi’s user identity scenarios was rescheduled for the next telecon due to time constraints.

Other: MikeF asked whether this group was also a catch-all for other issues such as caching, etc. MarkC thought no, others thought we have plenty to do on security issues to add other topics. Will raise this question in the next all-WSRP telecon.

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.

WSRP Security minutes 5/15

Attendees: Mark Cassidy, Jeff Broberg, Yossi Tamari, Adam Noland, Andre Kramur, Petr Palas, Thomas Schaek, Alejandro Abdelnur, Rich Thompson

Agenda:

Discussion of requirements related to access control and roles.

- The concept of roles was introduced in the context of allowing portlets to have their own access control mechanism. A common case is that a portlet provides some administrative function for editing the portlet’s configuration that exposes different parameters depending on the role of the user performing the edit function.

Another scenario could be a portlet that processes a purchase order; in this case the portlet might define levels of purchasing authority in terms of purchasing roles. A service request to this portlet would include role information for the end user which would be used by the portlet to determine whether the purchase order is processed or not.

Key discussion points:

1. Should WSRP support the ability for portlets to implement these types of access control functions?

Nobody suggested that this type of functionality should not be supported.

2. Should WSRP define standard roles?

Considerable debate over this. Several felt that without some standard names/semantics, roles would be problematic. Suggestion that we define some basic roles to prevent the situation where different portal implementations make different assumptions about roles which could result in the portlet not being interoperable across portal implementations. It was also argued that a proliferation of producer-defined roles would be difficult to support by portals.

Petr suggested some possible standard role definitions:

- administrator: access/modify basic/global settings

- editor: edit configuration settings(?)

- reader: views a portlet’s markup

The other side of the argument was that we should not call out specific role definitions. Dictating specific role behavior would be more or less arbitrary, and this would be too constraining and inflexible. Any given portlet could have a need for roles that are unique to that portlet and for which it doesn’t make sense to define a standard.

Alejandro stated that this issue was examined in JSR168 and that no standard roles were going to be specified as part of that initiative.

It was proposed that portlets be able to define their own roles in their metadata, and that portals should provide a means to map users/groups/roles known to the portal to the roles defined by the portlet. The portal would pass the appropriate role to the portlet with each service request based on the mapping established for the current user. In the case where the portlet defines roles but the portal can not assert them, it may still be possible to have integration but there could be a reduced level of functionality in this scenario.

After further discussion, a consensus emerged around the latter scenario. This is consistent with the direction of JSR168. One issue for additional consideration is how to ensure that role descriptions are clear and unambiguous, such that a portal administrator will know exactly what capabilities they are granting portal users through portlet role mappings.

There was additional discussion surrounding a suggestion by Alejandro that there be separation of interfaces and roles for administrative vs. non-administrative usage. Argument was that there could be cases where someone configuring an administrative setting on a portlet should not have access to the portlet’s content output if the nature of the content is highly sensitive, and having separate interfaces for administrative interaction with the portlet would be provide more security. General consensus was that:

a) this scenario could be accommodated with a single interface and appropriate role partitioning and access control enforcement by the portlet

b) single interface for invoking administrative and non-administrative actions did not pose a significantly increased security risk

3. Discussion closed on the issue of how to make it as easy as possible for portlet authors to implement the most common access control case, which is to differentiate access to administrative functions(mainly setting configuration parameters).

wsia message

Minutes from 4/3 WSRP Security Subgroup Telecon

Minutes from 4/10 WSRP Security Subgroup Telecon

Minutes from 4/24 WSRP Security Subgroup Telecon