[Mondrian] Re: xmla security header processing

Manuel Darveau manueldarveau at gmail.com
Tue May 3 15:26:40 EDT 2011


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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screen-capture.png
Type: image/png
Size: 18260 bytes
Desc: not available
Url : http://lists.pentaho.org/pipermail/mondrian/attachments/20110503/72d8cac3/attachment.png 


More information about the Mondrian mailing list