[Mondrian] Re: xmla security header processing

Luc Boudreau lucboudreau at gmail.com
Wed May 11 14:41:40 EDT 2011


Michele,

Your patch only modifies code that is not part of Olap4j nor Mondrian. Was
this a mistake? :)

Luc


On Tue, May 10, 2011 at 3:41 AM, Michele Rossi <michele.rossi at gmail.com>wrote:

> hi,
> I managed to create a patch file with all my changes using the command
> below.
> I've updated my perforce client to the latest version but there is still no
> trace of anything to do with creating patches in the context menus.
>
> thanks,
> Michele
>
>
> On 9 May 2011 20:30, Julian Hyde <jhyde at pentaho.com> wrote:
>
>>  'p4 diff -du' should be good enough.
>>
>>  ------------------------------
>> *From:* mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org]
>> *On Behalf Of *Luc Boudreau
>> *Sent:* Monday, May 09, 2011 9:01 AM
>>
>> *To:* Mondrian developer mailing list
>> *Cc:* Luc Boudreau
>>
>> *Subject:* Re: [Mondrian] Re: xmla security header processing
>>
>>
>> If you are using Eclipse, does the Perforce plugin add the "Create
>> patch..." option in the "Team" contextual menu? If so, then you could use
>> this.
>>
>>
>>
>> On Mon, May 9, 2011 at 11:58 AM, Michele Rossi <michele.rossi at gmail.com>wrote:
>>
>>> 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
>>>
>>> http://www.perforce.com/perforce/r10.1/manuals/p4eclipse/topics/patch.html
>>>
>>> <http://www.perforce.com/perforce/r10.1/manuals/p4eclipse/topics/patch.html>but
>>> 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.
>>>
>>> thanks,
>>> Michele
>>>
>>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/20110511/573fa00f/attachment.html 


More information about the Mondrian mailing list