<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19048"></HEAD>
<BODY>
<DIV><SPAN class=939123715-09052011><FONT color=#000080 size=2
face="Lucida Sans">Sorry, I missed this. I got your email of April 21st, and
will review in the next couple of days.</FONT></SPAN></DIV>
<DIV><SPAN class=939123715-09052011><FONT color=#000080 size=2
face="Lucida Sans"></FONT></SPAN> </DIV>
<DIV><SPAN class=939123715-09052011><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 class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> Michele Rossi
[mailto:michele.rossi@gmail.com] <BR><B>Sent:</B> Monday, May 09, 2011 8:27
AM<BR><B>To:</B> jhyde@pentaho.com; Mondrian developer mailing list; Luc
Boudreau<BR><B>Subject:</B> Re: [Mondrian] Re: xmla security header
processing<BR></FONT><BR></DIV>
<DIV></DIV>hi Julian and Luc,
<DIV>have you had a chance to take a look at the changes that I'd like to
submit?</DIV>
<DIV><BR></DIV>
<DIV>Is there anything unclear about my code that you would like to
discuss?</DIV>
<DIV><BR></DIV>
<DIV>If you don't think we should have these things in Mondrian I will try a
different approach, for example using the "xmla callback"
mechanism. </DIV>
<DIV>It's a long shot at this stage though, I am not sure it can work
yet.</DIV>
<DIV><BR></DIV>
<DIV>thanks,</DIV>
<DIV>Michele<BR><BR>
<DIV class=gmail_quote>On 21 April 2011 18:44, Michele Rossi <SPAN
dir=ltr><<A
href="mailto:michele.rossi@gmail.com">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>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
<DIV>
<DIV></DIV>
<DIV class=h5><BR><BR>
<DIV class=gmail_quote>On 21 April 2011 00:41, 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>
<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><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>
<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"
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></DIV></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>