[Mondrian] Re: xmla security header processing

Michele Rossi m.rossi at iontrading.com
Wed May 4 03:24:31 EDT 2011


hi,
interestingly I have the same version of Simba but the connection dialog
looks different - I don't have those advanced properties at all.

In any case I couldn't use your solution as one of my requirements is to
build a standard web app deployable in an old pre-existing tomcat server.
So I can't have my custom Security Handlers as you are doing in Jetty.

The best solution for me is to have the xmla servlet look at the security
information within the SOAP request itself.

thanks!
Michele

On 3 May 2011 21:26, Manuel Darveau <manueldarveau at gmail.com> wrote:

> Hi Michele,
>
> Sorry for the delay. I believe that the version of simba we are using
> is 4.3.6.14. If you look at the screen shot, there are additional
> options and the username/password are transfered to the authenticator.
>
> We had to put a custom org.mortbay.jetty.security.UserRealm into a
> org.mortbay.jetty.security.SecurityHandler and associate it to the
> org.mortbay.jetty.servlet.Context.
> The UserRealm receives the username/password from excel in it's
> com.eightd.ftk.jetty.configuration.DBUserRealm.authenticate(String,
> Object, Request) method.
>
> Manuel
>
> On Wed, Apr 27, 2011 at 6:28 AM, Michele Rossi <michele.rossi at gmail.com>
> wrote:
> > Hi Manuel,
> > I have the latest (as far as I know) version of SimbaO2X, 4.3.6.14 and I
> > don't see anything like that in Excel.
> > I have Excel 2007 and I've tried with both the available login dialogs -
> see
> > attached screenshots.
> > In any case a mechanism handled solely by the container wouldn't be great
> > for me as it's very likely that the underlying servlet wouldn't have
> access
> > to the security credentials.
> > I want to use them to open an authenticated Olap Connection.
> > thanks,
> > Michele
> >
> > On 27 April 2011 04:39, Manuel Darveau <manueldarveau at gmail.com> wrote:
> >>
> >> Hi Michele,
> >>
> >> You might want to take a look at the latest SimbaO2X version since it
> >> does support authentication at the servlet container level. In the
> >> connection dialog, there are username password textfields and a new
> >> checkbox to support cookie and thus, keeping session information. We
> >> just implemented a custom authentication integrated with an embedded
> >> jetty. I can provide some source if you want to. The only drawback
> >> with this approach is that is the user does not check the "cookie
> >> support" (whatever it is actually called), the authentication will be
> >> done on every request so you should implement a cache somehow.
> >>
> >> Since we don't use security/privileges on dimensions provided by
> >> mondrian, I can't tell if the logged in user is passed to mondrian.
> >>
> >> I think it would be a good idea to put a how-to on
> >> SimbaO2X/authentication/mondrian somewhere on the wiki.
> >>
> >> Manuel
> >>
> >> On Wed, Apr 20, 2011 at 4:15 PM, Michele Rossi <michele.rossi at gmail.com
> >
> >> wrote:
> >> > hi,
> >> > at the moment DefaultXmlaServlet simply ignores the XMLA SOAP security
> >> > information.
> >> > If there was ever anything like that in the code before it's certainly
> >> > been
> >> > removed now.
> >> > In Excel (with Simba) you can type a username and a password in the
> >> > dialog
> >> > used to create a connection to an xmla server.
> >> > Simba puts those two strings in a SOAP "Security" header that looks
> like
> >> > my
> >> > example below.
> >> > I already have a working "mod" of DefaultXmlaServlet that I have been
> >> > using
> >> > for a while capable of reading and using that security header.
> >> > Going back to your question about containers: it's certainly possible
> to
> >> > protect access to "/xmla" using a standard http authentication
> >> > mechanisms
> >> > but Simba doesn't support any of that.
> >> > Also even if Simba supported it the container would certainly not pass
> >> > the
> >> > authentication information to the XMLA servlet.
> >> > And the biggest deal for me is using the credentials provided in Excel
> >> > to
> >> > open an authenticated Olap4j connection.
> >> > I will put together a prototype in the next few days, I think it will
> be
> >> > easier to discuss this with a piece of code to look at.
> >> > thanks,
> >> > Michele
> >> >
> >> > On 20 April 2011 21:19, Julian Hyde <jhyde at pentaho.com> wrote:
> >> >>
> >> >> I'd rather not spend hours researching this. But authentication
> >> >> problems
> >> >> have been solved countless times before in the XMLA server code base.
> >> >> Including authentication from Simba O2X. Can you look over the code
> and
> >> >> the
> >> >> checkin history and find out how the previous solutions did it.
> >> >>
> >> >> If there is someone on the developers list who has worked on these
> >> >> issues,
> >> >> please speak up now.
> >> >>
> >> >> Julian
> >> >>
> >> >> ________________________________
> >> >> From: Michele Rossi [mailto:michele.rossi at gmail.com]
> >> >> Sent: Wednesday, April 20, 2011 10:52 AM
> >> >> To: <jhyde at pentaho.com>
> >> >> Cc: Mondrian developer mailinglist
> >> >> Subject: Re: xmla security header processing
> >> >>
> >> >> hi,
> >> >> as far as I know Axis is not a container but a library to create SOAP
> >> >> web
> >> >> services.
> >> >> There is nothing a container can do with that security information as
> >> >> it's
> >> >> not transferred in a standard http way.
> >> >> The username and password that you type in Excel when you create a
> new
> >> >> SimbaO2x connection are sent to the server in the request header xml
> >> >> element
> >> >> that I copied below.
> >> >> So we either modify the xmla servlet or create an xmla callback with
> >> >> the
> >> >> same features.
> >> >> Do you agree on the general principle that the client (excel)
> >> >> credentials
> >> >> should be used to open the olap4j connection?
> >> >> And that the session id should be used to retrieve existing
> >> >> connections?
> >> >> You certainly can't delegate any of these two features to the
> >> >> container.
> >> >> thanks!
> >> >> Michele
> >> >>
> >> >> Sent from my iPhone
> >> >> On 20 Apr 2011, at 18:19, "Julian Hyde" <jhyde at pentaho.com> wrote:
> >> >>
> >> >> I'm not an expert on the HTTP/SOAP stuff. But the general goal should
> >> >> be
> >> >> to let the container (e.g. tomcat or apache axis) manage as much of
> >> >> this
> >> >> stuff as possible. Maybe you can see how people have made
> >> >> authentication
> >> >> work elsewhere in the XMLA servlet.
> >> >>
> >> >> Julian
> >> >>
> >> >> ________________________________
> >> >> From: Michele Rossi [mailto:michele.rossi at gmail.com]
> >> >> Sent: Wednesday, April 20, 2011 8:00 AM
> >> >> To: Mondrian developer mailing list
> >> >> Cc: jhyde at pentaho.com
> >> >> Subject: xmla security header processing
> >> >>
> >> >> Hi,
> >> >> I am writing some code to handle the xmla security header:
> >> >> <Header>
> >> >>                        <Security
> >> >> xmlns="http://schemas.xmlsoap.org/ws/2002/04/secext">
> >> >>                            <UsernameToken>
> >> >>                                <Username>MICHELE</Username>
> >> >>                                <Password
> >> >> Type="PasswordText">ROSSI</Password>
> >> >>                            </UsernameToken>
> >> >>                        </Security>
> >> >>                        <BeginSession mustUnderstand="1"
> >> >> xmlns="urn:schemas-microsoft-com:xml-analysis" />
> >> >>                     </Header>
> >> >> Such header is sent out by XMLA clients such as SimbaO2X (Excel
> >> >> plugin).
> >> >> My idea is to pass user credentials down to the connection manager
> and
> >> >> use
> >> >> them to create new connections.
> >> >> I also think that connections should be associated with sessions.
> >> >> I am thinking of a Map that associates session IDs with
> OlapConnection
> >> >> objects.
> >> >> I can put all this logic directly in DefaultXmlaServlet or (probably)
> >> >> in a
> >> >> "XmlaRequestCallback" class.
> >> >> Which option do we want to go for?
> >> >> I also have in mind another more specific bit of functionality:
> hiding
> >> >> username / password in the session ID returned to the xmla client.
> >> >> This can be useful especially in the case of a server going down and
> >> >> forgetting a particular session id.
> >> >> (Your user leaves Excel open for a couple of days and when he tries
> to
> >> >> use
> >> >> the Pivot again he gets an error if the server has been bounced in
> the
> >> >> meantime).
> >> >> The other use case could be http load balancers.
> >> >> As Excel does not send any cookies most load balancers would fail to
> >> >> apply
> >> >> the "sticky session" policy and could redirect different xmla
> requests
> >> >> to
> >> >> different cluster members.
> >> >> Only one of those members would know about the specified session ID
> (in
> >> >> other words only one of those servers would have an OlapConnection
> >> >> object
> >> >> stored under the given session id) but the others could re-obtain the
> >> >> credentials by de-crypting the session id.
> >> >> I can make the encrypted session ID very secure - even to "clear
> text"
> >> >> attacks.
> >> >> I will discuss the details only if we think it's a feature worth
> >> >> having.
> >> >> Michele
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Mondrian mailing list
> >> > Mondrian at pentaho.org
> >> > http://lists.pentaho.org/mailman/listinfo/mondrian
> >> >
> >> >
> >> _______________________________________________
> >> Mondrian mailing list
> >> Mondrian at pentaho.org
> >> http://lists.pentaho.org/mailman/listinfo/mondrian
> >
> >
> > _______________________________________________
> > Mondrian mailing list
> > Mondrian at pentaho.org
> > http://lists.pentaho.org/mailman/listinfo/mondrian
> >
> >
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>


-- 

*
*

*Michele Rossi*

Via San Martino, 52, 56125 Pisa, ITALY
T: +39 050 220 3894
m.rossi at iontrading.com
http://www.iontrading.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110504/0a4aca85/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1461 bytes
Desc: not available
Url : http://lists.pentaho.org/pipermail/mondrian/attachments/20110504/0a4aca85/attachment.jpe 


More information about the Mondrian mailing list