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