Mashup Authorization Authentication Requirements

From MemberWiki

Jump to: navigation, search

Authentication and authorization requirements for mashups

This section is intended to capture requirements for authentication and authorization in mashups to boostrap a discussion on how this might be affect the gadget loading lifecycle and potentially features on the Hub.

Authentication

The use case scenario is a top level mashup page which loads third party gadgets and how users authenticate to the third party servers before these gadgets or, to be more exact, the services or data that the gadgets access are loaded. The user can either authenticate directly to the gadget server i.e. authenticates once to the mashup page and once to each gadget server which requires it or there is a single sign-on to all the mashup page and all the gadgets on the page. The single sign-on scenario requires some form of identity federation with the mashup server as the identity provider. Some use case scenarios for authentication that we have seen in deployments are the following

1. Authentication at the Gadget Server : MAA Use Case UseridPwd

2. Mashup Server provides a SAML identity token while loading gadget: MAA Use Case SAML

3. Mashup server acts as Openid Provider for gadget server: MAA Use Case OpenID

We have described only scenarios where the mashup server is the identity provider. It is possible that there are use cases where there is a third-party identity provider. Similarly, we've described only SAML identity assertion and OpenID as the possible federation protocols, there is no particular reason to assume that these are the only possible tokens or protocols. Any protocol or other standardization effort must allow for an arbitrary token to be used ( and potentially an arbitrary protocol as well although that looks a little more difficult).

What can we do in this forum? First we need to make sure that these authentication protocol flows would not conflict with any decisions we've made on Hub1.1 For instance, the delays due to authentication may violate the timing restrictions in the SMash provider. The other possiblility is we could standardize on certain parameters to be passed in with the gadget load requests. Finally (although its not clear we want to go there) we could standardize on some protocol or federation token.

Authorization requirements for data access in mashups:

The following are some data-access authorization requirements we have seen in deployments. For this description it helps to think of a scenario where we have a mashup server (MS) which servers a mashup page (MP). The Mashup Page then loads a gadget (G) from a gadget server (GS). Finally there is a service provider (S) who provides a service (or some data) which is invoked by the one of the other entities as described below:

a. Plain-vanilla user authorization: A gadget or the mashup page accesses a service on its home server which has to enforce the user's authorization to this data or the service. Standard web security issue here.

b. Authorization to a backend service behind the mashup server A gadget ( or the mashup page) access as a service on the gadget server ( or mashup server) which then invokes a service or gets data from a backend service on behalf of the user. This is done with

b1. A system credential.
b2. A user supplied credential. This is further classified as
b21: The user supplied credential is the user's id/password. Although this is insecure we have seen a number of deployments where this is used. Our recommendation should be that this is insecure and should NOT be used
b22: A delegated credential using a protocol such as OAuth which should be our recommendation.

c. Purely client side authorization: This is the case when gadgets on a mashup page need to authorize the exchange of data. The only case we have seen is the mashup page essentially performing this authorization of which gadgets talk to each other. This is enabled by our current vision for the Hub.

As yet, we have seen no requirements around pure client side authorization i.e. one gadget authorizing another gadget.

d. Other potential authorization scenarios: There could be other authorization scenarios which might be useful to discuss.

Personal tools