hi,<div>I've made several changes to DefaultXmlaServlet / XmlaRequest etc making them capable of using the SOAP credentials to create new OLAP connections.</div><div><br></div><div>I've tested the code with the following configuration: Excel 2007 with SimbaO2X --> A standalone tomcat server running Olap4jXmlaServlet --> olap4j XMLA driver pointing to a standard mondrian installation running FoodMart.</div>
<div><br></div><div>You will find a few bits which are to do with the way Excel 2007 and Simba O2X behave.</div><div>Let me know if you think they are too specific and we don't want to have them in the code.</div><div>
<br></div><div><br></div><div><br></div><div>XMLA has a concept of session ID which I leverage to store new OlapConnection objects and retrieve them when new requests arrive with a session ID for which a connection is already available.</div>
<div><br></div><div>This might sound unnecessarily complicated but I think it is essential, at least for SimbaO2X.</div><div>Without this mechanism Simba would trigger the creation of lots of connections and that would be slow and memory expensive.</div>
<div><br></div><div>I've further refined this mechanism by creating a session id based on the hashcode of the username and (when I finish it) the IP of the remote client host.</div><div>This will mean that even fewer unnecessary connections are created and things are a lot faster.</div>
<div><br></div><div>My changes are mostly in XmlaHandler and DefaultXmlaServlet. </div><div>I didn't touch any of the MondrianServer classes. </div><div>I wanted this mechanism to be applicable to any OLAP4J provider.</div>
<div><br></div><div>I am aware that I've made a high number of changes.</div><div>It wouldn't have been possible to do what I wanted with anything less though.</div><div>Hope you don't find the changes too hard to review.</div>
<div><br></div><div>As with my previous code changes, searching for [MROSSI] should help you find my new code.</div><div><br></div><div>Many thanks!</div><div>Michele<br><br><div class="gmail_quote">On 21 April 2011 00:41, Julian Hyde <span dir="ltr"><<a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<div><span><font color="#000080" size="2" face="Lucida Sans">Don't change mondrian.server.Repository.getConnection; by
that time, the user should be authenticated and a role should be
known.</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">Instead, create a method</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">void
MondrianServer.getConnectionUnauthenticated(</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"> String userName,</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"> String password,</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"> String catalogName,</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"> String schemaName,</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"> Properties properties)</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">Note that it is like</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">void MondrianServer.getConnection(</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"> String catalogName,</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"> String schemaName,</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"> String roleName,</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"> Properties props);</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">except that 'role' is removed and 'userName' and 'password'
have been added. MondrianServer should then authenticate, and call
Repository.getConnection.</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">If MondrianServer needs a database of usernames and
passwords, and how they map to roles, please use JAAS for that. I believe it is
the standard for such things.</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">Julian</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div><font color="#000080" size="2" face="Lucida Sans"></font><br>
<blockquote style="border-left:#000080 2px solid;padding-left:5px;margin-left:5px;margin-right:0px">
<div dir="ltr" lang="en-us" align="left">
<hr>
<font size="2" face="Tahoma"><b>From:</b> <a href="mailto:mondrian-bounces@pentaho.org" target="_blank">mondrian-bounces@pentaho.org</a>
[mailto:<a href="mailto:mondrian-bounces@pentaho.org" target="_blank">mondrian-bounces@pentaho.org</a>] <b>On Behalf Of </b>Luc
Boudreau<br><b>Sent:</b> Wednesday, April 20, 2011 2:22 PM<div class="im"><br><b>To:</b>
Mondrian developer mailing list<br></div><b>Subject:</b> Re: [Mondrian] Re: xmla
security header processing<br></font><br></div><div><div></div><div class="h5">
<div></div><br>Michele,<br><br>I understand your requirement. You want to
passthrough the credentials through the servlet down to the OlapConnection.
The architecture of the Mondrian Server was not designed with that in mind, so
my concern is that such a feature is integrated 'the right way'. The proper
way to do this would be to modify the mondrian.server.Repository#getConnection
method to take a user and password as arguments. One downside is that we will
depend on Java Services Discovery to register the olap4j driver with the
DriverManager. One thing I don't like about that approach is the fact that the
server becomes 'aware' of the requests contents. I guess this was unavoidable
as soon as we attempted to factor out the Mondrian Server in it's own
project.<br><br>Write up some code and send it to this list. As you said,
better discuss over code than concepts :)<br><br>Luc<br><br><br><br>
<div class="gmail_quote">On Wed, Apr 20, 2011 at 4:15 PM, Michele Rossi <span dir="ltr"><<a href="mailto:michele.rossi@gmail.com" target="_blank">michele.rossi@gmail.com</a>></span>
wrote:<br>
<blockquote style="border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;padding-left:1ex" class="gmail_quote">hi,
<div>at the moment DefaultXmlaServlet simply ignores the XMLA SOAP security
information.</div>
<div>If there was ever anything like that in the code before it's certainly
been removed now.</div>
<div><br></div>
<div>
<div>In Excel (with Simba) you can type a username and a password in the
dialog used to create a connection to an xmla server.</div>
<div>Simba puts those two strings in a SOAP "Security" header that looks
like my example below.</div></div>
<div><br></div>
<div>I already have a working "mod" of DefaultXmlaServlet that I have been
using for a while capable of reading and using that security header.</div>
<div><br></div>
<div>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. </div>
<div>Also even if Simba supported it the container would certainly not pass
the authentication information to the XMLA servlet.</div>
<div><br></div>
<div>And the biggest deal for me is using the credentials provided in Excel
to open an authenticated Olap4j connection.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>thanks,</div>
<div>Michele</div>
<div>
<div></div>
<div>
<div><br>
<div><br>
<div class="gmail_quote">On 20 April 2011 21:19, Julian Hyde <span dir="ltr"><<a href="mailto:jhyde@pentaho.com" target="_blank">jhyde@pentaho.com</a>></span> wrote:<br>
<blockquote style="border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;padding-left:1ex" class="gmail_quote">
<div bgcolor="#ffffff">
<div><span><font color="#000080" size="2" face="Lucida Sans">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.</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">If there is
someone on the developers list who has worked on these issues, please
speak up now.</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">Julian</font></span></div><br>
<blockquote style="border-left:#000080 2px solid;padding-left:5px;margin-left:5px;margin-right:0px" dir="ltr">
<div dir="ltr" lang="en-us" align="left">
<hr>
<font size="2" face="Tahoma">
<div><b>From:</b> Michele Rossi [mailto:<a href="mailto:michele.rossi@gmail.com" target="_blank">michele.rossi@gmail.com</a>] <br></div><b>Sent:</b>
Wednesday, April 20, 2011 10:52 AM<br><b>To:</b> <<a href="mailto:jhyde@pentaho.com" target="_blank">jhyde@pentaho.com</a>><br><b>Cc:</b> Mondrian developer
mailinglist<br><b>Subject:</b> Re: xmla security header
processing<br></font><br></div>
<div>
<div></div>
<div>
<div></div>
<div>hi,</div>
<div>as far as I know Axis is not a container but a library to create
SOAP web services.</div>
<div><br></div>
<div>There is nothing a container can do with that security information
as it's not transferred in a standard http way.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>So we either modify the xmla servlet or create an xmla callback
with the same features.</div>
<div><br></div>
<div>Do you agree on the general principle that the client (excel)
credentials should be used to open the olap4j connection?</div>
<div><br></div>
<div>And that the session id should be used to retrieve existing
connections?</div>
<div>You certainly can't delegate any of these two features to the
container.</div>
<div><br></div>
<div>thanks!</div>
<div>Michele <br><br>Sent from my iPhone</div>
<div><br>On 20 Apr 2011, at 18:19, "Julian Hyde" <<a href="mailto:jhyde@pentaho.com" target="_blank">jhyde@pentaho.com</a>>
wrote:<br><br></div>
<div></div>
<blockquote type="cite">
<div>
<div><span><font color="#000080" size="2" face="Lucida Sans">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.</font></span></div>
<div><span><font color="#000080" size="2" face="Lucida Sans"></font></span> </div>
<div><span><font color="#000080" size="2" face="Lucida Sans">Julian</font></span></div><br>
<blockquote style="border-left:#000080 2px solid;padding-left:5px;margin-left:5px;margin-right:0px" dir="ltr">
<div dir="ltr" lang="en-us" align="left">
<hr>
<font size="2" face="Tahoma"><b>From:</b> Michele Rossi [mailto:<a href="mailto:michele.rossi@gmail.com" target="_blank">michele.rossi@gmail.com</a>] <br><b>Sent:</b>
Wednesday, April 20, 2011 8:00 AM<br><b>To:</b> Mondrian developer
mailing list<br><b>Cc:</b> <a href="mailto:jhyde@pentaho.com" target="_blank"></a><a href="mailto:jhyde@pentaho.com" target="_blank">jhyde@pentaho.com</a><br><b>Subject:</b> xmla security
header processing<br></font><br></div>
<div></div>Hi,
<div><br></div>
<div>I am writing some code to handle the xmla security
header:</div>
<div><br></div>
<div>
<div><Header></div>
<div><span style="white-space:pre-wrap"></span>
<Security xmlns="<a href="http://schemas.xmlsoap.org/ws/2002/04/secext" target="_blank"></a><a href="http://schemas.xmlsoap.org/ws/2002/04/secext" target="_blank">http://schemas.xmlsoap.org/ws/2002/04/secext</a>"></div>
<div><span style="white-space:pre-wrap"></span>
<UsernameToken></div>
<div><span style="white-space:pre-wrap"></span>
<Username>MICHELE</Username></div>
<div><span style="white-space:pre-wrap"></span>
<Password
Type="PasswordText">ROSSI</Password></div>
<div><span style="white-space:pre-wrap"></span>
</UsernameToken></div>
<div><span style="white-space:pre-wrap"></span>
</Security></div>
<div><span style="white-space:pre-wrap"></span>
<BeginSession mustUnderstand="1"
xmlns="urn:schemas-microsoft-com:xml-analysis" /></div>
<div><span style="white-space:pre-wrap"></span>
<span style="white-space:pre-wrap"> </span></Header></div></div>
<div><br></div>
<div>Such header is sent out by XMLA clients such as SimbaO2X (Excel
plugin).</div>
<div>My idea is to pass user credentials down to the connection
manager and use them to create new connections.</div>
<div><br></div>
<div>I also think that connections should be associated with
sessions.</div>
<div>I am thinking of a Map that associates session IDs with
OlapConnection objects.</div>
<div><br></div>
<div>I can put all this logic directly in DefaultXmlaServlet or
(probably) in a "XmlaRequestCallback" class.</div>
<div>Which option do we want to go for?</div>
<div><br></div>
<div>I also have in mind another more specific bit of functionality:
hiding username / password in the session ID returned to the xmla
client.</div>
<div>This can be useful especially in the case of a server going
down and forgetting a particular session id.</div>
<div>(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).</div>
<div><br></div>
<div>The other use case could be http load balancers.</div>
<div>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.</div>
<div>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.</div>
<div><br></div>
<div>I can make the encrypted session ID very secure - even to
"clear text" attacks.</div>
<div>I will discuss the details only if we think it's a feature
worth having.</div>
<div><br></div>
<div>Michele</div>
<div><br></div>
<div><br></div></blockquote></div></blockquote></div></div></blockquote></div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>Mondrian
mailing list<br><a href="mailto:Mondrian@pentaho.org" target="_blank">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></blockquote></div><br></div></div></blockquote></div>
<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>
<br></blockquote></div><br></div>