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&#39;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 &quot;Security&quot; header that looks like my example below.</div>

</div><div><br></div><div>I already have a working &quot;mod&quot; 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&#39;s certainly possible to protect access to &quot;/xmla&quot; using a standard http authentication mechanisms but Simba doesn&#39;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><br><div><br>

<div class="gmail_quote">On 20 April 2011 21:19, Julian Hyde <span dir="ltr">&lt;<a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">





<div bgcolor="#ffffff">
<div><span><font color="#000080" size="2" face="Lucida Sans">I&#39;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 class="im"><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> &lt;<a href="mailto:jhyde@pentaho.com" target="_blank">jhyde@pentaho.com</a>&gt;<br><b>Cc:</b> Mondrian 
  developer mailinglist<br><b>Subject:</b> Re: xmla security header 
  processing<br></font><br></div><div><div></div><div class="h5">
  <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&#39;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&#39;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, &quot;Julian Hyde&quot; &lt;<a href="mailto:jhyde@pentaho.com" target="_blank">jhyde@pentaho.com</a>&gt; wrote:<br><br></div>
  <div></div>
  <blockquote type="cite">
    <div>
    <div><span><font color="#000080" size="2" face="Lucida Sans">I&#39;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>&lt;Header&gt;</div>
      <div><span style="white-space:pre-wrap"></span>  
                          
       &lt;Security xmlns=&quot;<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>&quot;&gt;</div>


      <div><span style="white-space:pre-wrap"></span>  
                          
           &lt;UsernameToken&gt;</div>
      <div><span style="white-space:pre-wrap"></span>  
                          
              
       &lt;Username&gt;MICHELE&lt;/Username&gt;</div>
      <div><span style="white-space:pre-wrap"></span>  
                          
               &lt;Password 
      Type=&quot;PasswordText&quot;&gt;ROSSI&lt;/Password&gt;</div>
      <div><span style="white-space:pre-wrap"></span>  
                          
           &lt;/UsernameToken&gt;</div>
      <div><span style="white-space:pre-wrap"></span>  
                          
       &lt;/Security&gt;</div>
      <div><span style="white-space:pre-wrap"></span>  
                          
       &lt;BeginSession mustUnderstand=&quot;1&quot; 
      xmlns=&quot;urn:schemas-microsoft-com:xml-analysis&quot; /&gt;</div>
      <div><span style="white-space:pre-wrap"></span>  
                       <span style="white-space:pre-wrap"> 
      </span>&lt;/Header&gt;</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 &quot;XmlaRequestCallback&quot; 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 &quot;sticky session&quot; 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 &quot;clear 
      text&quot; attacks.</div>
      <div>I will discuss the details only if we think it&#39;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>