[Mondrian] Re: xmla security header processing

Luc Boudreau lucboudreau at gmail.com
Wed May 18 11:47:53 EDT 2011


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110518/434f6dae/attachment.html 


More information about the Mondrian mailing list