[Mondrian] Re: xmla security header processing

Michele Rossi michele.rossi at gmail.com
Wed Apr 27 06:28:20 EDT 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110427/db9490c4/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: excel_login_dialog2.PNG
Type: image/png
Size: 12874 bytes
Desc: not available
Url : http://lists.pentaho.org/pipermail/mondrian/attachments/20110427/db9490c4/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: excel_login_dialog1.PNG
Type: image/png
Size: 14993 bytes
Desc: not available
Url : http://lists.pentaho.org/pipermail/mondrian/attachments/20110427/db9490c4/attachment-0001.png 


More information about the Mondrian mailing list