[Mondrian] Re: xmla security header processing

Michele Rossi michele.rossi at gmail.com
Wed May 18 12:50:02 EDT 2011


hi,
apologies for that - I assumed that Julian was looking at my changes using
the java files I sent.

So I finally managed to make the patch file - hopefully with the shape that
you expect.

It might be possible to implement some of my changes as Xmla Callback
handlers - it's something I can explore.

thanks,
Michele


On 18 May 2011 16:47, Luc Boudreau <lucboudreau at gmail.com> wrote:

> Michele,
>
> The last patch you sent didn't have any code changes related to Mondrian
> nor olap4j. You said you would submit a new patch. Maybe it didn't make it
> through, but still, I didn't get it.
>
> Luc
>
>
>
> On Wed, May 18, 2011 at 11:35 AM, Michele Rossi <michele.rossi at gmail.com>wrote:
>
>> hi,
>> did you have a chance to look at my xmla changes?
>>
>> The general ideas behind them are simple:
>>
>> 1. Pass the credentials provided in Excel down to the method that creates
>> an OlapConnection.
>> 2. Leverage the concept of Session ID (already present in XMLA) to store
>> and retrieve the right authenticated connection for subsequent requests.
>>
>> What's currently missing is a connection clean up mechanism.
>> I didn't want to invest time on it before my other changes were accepted.
>>
>> thanks,
>> Michele
>>
>>
>> On 9 May 2011 16:37, Julian Hyde <jhyde at pentaho.com> wrote:
>>
>>>  Sorry, I missed this. I got your email of April 21st, and will review
>>> in the next couple of days.
>>>
>>> Julian
>>>
>>>  ------------------------------
>>> *From:* Michele Rossi [mailto:michele.rossi at gmail.com]
>>> *Sent:* Monday, May 09, 2011 8:27 AM
>>> *To:* jhyde at pentaho.com; Mondrian developer mailing list; Luc Boudreau
>>>
>>> *Subject:* Re: [Mondrian] Re: xmla security header processing
>>>
>>> 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/20110518/a6bf5c87/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: michele.patch
Type: application/octet-stream
Size: 26197 bytes
Desc: not available
Url : http://lists.pentaho.org/pipermail/mondrian/attachments/20110518/a6bf5c87/attachment.obj 


More information about the Mondrian mailing list