[Mondrian] Re: xmla security header processing
Luc Boudreau
lucboudreau at gmail.com
Mon May 9 11:30:43 EDT 2011
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20110509/e8c524bd/attachment.html
More information about the Mondrian
mailing list