[Mondrian] Re: xmla security header processing

Michele Rossi michele.rossi at gmail.com
Mon May 9 11:58:36 EDT 2011

Hi Luc,
I am currently unable to generate patch files with perforce and I am not
sure why.

I found the following link on the subject

such menu item does not exist in my p4 windows client (v 2009.1/212209) nor
it does in my eclipse p4 plugin.

I have to leave for the day now but I will try to find a way to generate
patch files tomorrow.


On 9 May 2011 17:30, Luc Boudreau <lucboudreau at gmail.com> wrote:

> Michele,
> Could you provide a patch file rather than a bunch of Java files? Please
> generate those diff files against //open/mondrian (the Mondrian 3.3 branch).
> Thanks!
> Luc
> On Mon, May 9, 2011 at 11:27 AM, Michele Rossi <michele.rossi at gmail.com>wrote:
>> hi Julian and Luc,
>> have you had a chance to take a look at the changes that I'd like to
>> submit?
>> Is there anything unclear about my code that you would like to discuss?
>>  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.
>> It's a long shot at this stage though, I am not sure it can work yet.
>> thanks,
>> Michele
>> On 21 April 2011 18:44, Michele Rossi <michele.rossi at gmail.com> wrote:
>>> hi,
>>> I've made several changes to DefaultXmlaServlet / XmlaRequest etc making
>>> them capable of using the SOAP credentials to create new OLAP connections.
>>> 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.
>>> You will find a few bits which are to do with the way Excel 2007 and
>>> Simba O2X behave.
>>> Let me know if you think they are too specific and we don't want to have
>>> them in the code.
>>> 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.
>>> This might sound unnecessarily complicated but I think it is essential,
>>> at least for SimbaO2X.
>>> Without this mechanism Simba would trigger the creation of lots of
>>> connections and that would be slow and memory expensive.
>>> 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.
>>> This will mean that even fewer unnecessary connections are created and
>>> things are a lot faster.
>>> My changes are mostly in XmlaHandler and DefaultXmlaServlet.
>>> I didn't touch any of the MondrianServer classes.
>>> I wanted this mechanism to be applicable to any OLAP4J provider.
>>> I am aware that I've made a high number of changes.
>>> It wouldn't have been possible to do what I wanted with anything less
>>> though.
>>> Hope you don't find the changes too hard to review.
>>> As with my previous code changes, searching for [MROSSI] should help you
>>> find my new code.
>>> Many thanks!
>>> Michele
>>> On 21 April 2011 00:41, Julian Hyde <jhyde at pentaho.com> wrote:
>>>>  Don't change mondrian.server.Repository.getConnection; by that time,
>>>> the user should be authenticated and a role should be known.
>>>> Instead, create a method
>>>> void MondrianServer.getConnectionUnauthenticated(
>>>>  String userName,
>>>>  String password,
>>>>  String catalogName,
>>>>  String schemaName,
>>>>  Properties properties)
>>>> Note that it is like
>>>> void MondrianServer.getConnection(
>>>>     String catalogName,
>>>>     String schemaName,
>>>>     String roleName,
>>>>     Properties props);
>>>> except that 'role' is removed and 'userName' and 'password' have been
>>>> added. MondrianServer should then authenticate, and call
>>>> Repository.getConnection.
>>>> 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.
>>>> Julian
>>>>  ------------------------------
>>>> *From:* mondrian-bounces at pentaho.org [mailto:
>>>> mondrian-bounces at pentaho.org] *On Behalf Of *Luc Boudreau
>>>> *Sent:* Wednesday, April 20, 2011 2:22 PM
>>>> *To:* Mondrian developer mailing list
>>>> *Subject:* Re: [Mondrian] Re: xmla security header processing
>>>> Michele,
>>>> 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.
>>>> Write up some code and send it to this list. As you said, better discuss
>>>> over code than concepts :)
>>>> Luc
>>>> 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>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>
>>>>>> 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
>> _______________________________________________
>> 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/20110509/bbe6848b/attachment.html 

More information about the Mondrian mailing list