[Mondrian] Re: xmla security header processing
Michele Rossi
michele.rossi at gmail.com
Fri May 20 12:58:00 EDT 2011
hi,
I've just identified an issue in the code I've sent - in Rowset.java the
OlapConnection are closed after use: that doesn't work well with the idea of
caching the connection (storing it under the XMLA session id).
I think we should have a clean up thread that closes connections after a
period of inactivity.
What do you think?
thanks,
Michele
public final void populate(
XmlaResponse response,
OlapConnection connection,
List<Row> rows)
throws XmlaException
{
boolean ourConnection = false;
try {
if (needConnection() && connection == null) {
connection = handler.getConnection(request);
ourConnection = true;
}
populateImpl(response, connection, rows);
} catch (SQLException e) {
// TODO:
e.printStackTrace();
} finally {
if (connection != null && ourConnection) {
try {
connection.close();
} catch (SQLException e) {
// ignore
}
}
}
}
On 18 May 2011 17:50, Michele Rossi <michele.rossi at gmail.com> wrote:
> 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/20110520/f892ead0/attachment.html
More information about the Mondrian
mailing list