SECURITY USING CELL-SECURITY:

From what i've read cell security s enforced on the client. If someone
is able to gain access to a machine running the client (for example an
application server or a web server) he is able to get cell values
independently of the fact that those values will be defined as #N/A in
the secured cell value property. The real value is travelling between
theAnalysis Server and the application server. Is this true ? How can we
effectively garantee true security ?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Analysis Services offers two modes of enforcing security: on the client and
on the server. If you are concerned that the secured data can be intercepted
in the communication - you should use server enforcement - in this case
secured data will never leave server.
You can use dimension security with server enforcement.

--
==================================================
Mosha Pasumansky - http://www.mosha.com/msolap
Development Lead in the Analysis Server team
All you need is love (John Lennon)
Disclaimer : This posting is provided "AS IS" with no warranties, and
confers no rights.
==================================================
"joao rodrigues" <jhrodrigues (AT) bportugal (DOT) pt> wrote

Does this mean there are no ways of implementing Cell
Security with server enforcement in SQL Server 2000.

THAT'S EXACTLY THE PROBLEM !

Our only way to implement security in AS is using Cell-Security beacause
the roles to implement are mainly : IF Users chooses Member A from Dim A
and Member B from Dim B, than he is not allowed to see the values. Rules
are realy very complex !

I Need some additional clarification, expecially from Moshua!

1 ) Is there a way to use cell-security (with enforcement on
client-side) but changing the Secured Cell Value Property to another
value that tell Analysis Server NOT TO SEND BACK the real Confidencial
value ? Which problems are in changing these value with the Isolation
Mode defined also in the connection ?

2 ) I've started to try applying the MDX used in cell-security within a
calculated cell, which gives me the value of 0 (not allowed) and 1
(allowed). This is good as i can use these calculated cell to find out
if the current cell value is allowed for a public profile. A second
measure will always have the real value. So i will have two calculated
members : one which has the public value or the string "Sec" and another
one which has always the real value. A user connecting with a public
profile will see the first value, a user connecting with a private
profile will see the second value. The problem is that i cannot use
dimension security on calculated members to filter which calculated
emmber each role can see. And i realy need to use calculated members
because i need to use server-side coloring ! I think i am almost getting
there as i already have tweo calculated members for each of the roles :
a fiorst that has public values and "Sec" and a second which has all the
values with a red color on those defined as public ! IS THERE ANY WAY OF
KNOWING USING MDX WHICH ROLE IS THE CURRENT LOGGED ON USER IN ? If so i
will use expliity these value to have another calculated member saying :
If CURRENT USER IS IN PUBLIC ROLE, Then value is the first value, else
value is the second value



*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

With cell security it is not possible to do server enforcement in AS2K. It
will possible in Yukon.


Trying to substitute security with calculated cells or calculated members
simply won't work. You still won't be able to make them enforced on server,
but instead you will open additional holes.
Here are my suggestions:

1. Use HTTPS as the only protocol to connect to Analysis Services - i.e.
close ports 2725 and 2393/4 in the Analysis Server machine. HTTPS uses SSL
for encrypting the data - so nobody will be able to intercept
2. Adopt server-only solution, for example XMLA SDK - where all of the
security checks happen on the server machine. There are commercial products
which allow such middle tier solutions - Proclarity, NovaView - to name a
couple.

--
==================================================
Mosha Pasumansky - http://www.mosha.com/msolap
Development Lead in the Analysis Server team
All you need is love (John Lennon)
Disclaimer : This posting is provided "AS IS" with no warranties, and
confers no rights.
==================================================

1 ) Don't understand why using calculated cells will not work and also
why does it open security risks. CAN YOU CLARIFY ?
Suppose that i have 2 roles: (1) public and (2) private. Second role
will see all values, first role will se values returned by MDX
statement.
If i use two measures (taken from the same value) then i will define one
calculated cell (calculation subcube will be the measure, calculation
value will be the MDX Statement taken from cell security) named RILE
PUBLIC. This will produce 0 (not allowed) or 1 (allowed). Then i will
use another calculated cell (NAMED PUBLIC VALUE) which is something like
: If Allowed the Value, otherwise "Sec". Another calculated cell
(PRIVATE VALUE) will keep always the real value.
One user connecting with Public role wil see the PUBLIC VALUE (value or
the string "Sec"), another user connecting with the second role will see
always the real value (PRIVATE VALUE) and these is always done on the
server side. WHY DOES THIS NOT WORK AND WHY DOES THIS OPEN ADDITIONAL
HOLES ? (WE WILL ALWAYS USE IPSEC OR HTTPS BETWEEN OUR APPLICATION
SERVER AND ANALYSIS SERVER).

2 ) We will intend to use in fact HTTPS between Proclarity and Analysis
Server. Our problem is not that someone will be able to intercept the
values from the connection but that someone will hijack the current
session id of a public user that is currently authenticated and manages
to get the values taken from AS , as cell-security will be enfornce on
the client (in these case Proclarity application server). We think that
even using Proclarity as a middle tier solution and using HTTPS between
Proclatiry and Analysis Services there is a security risk that someone
will hijack a public session and manages to access Analysis server cubes
using cell-security, anf getting values not allowed for that profile. IS
THIS TRUE ?

WE REALLY NEED SOME HELP IN TRYING TO CLARITY WHICH SECURITY RISKS ARE
IN PLACE !

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

I did not say that calculated cells won't work for you, but they won't let
you achive something that cell security didn't

I am not clear whether you mean Proclarity's session ids or AS session ids.
If you mean Proclarity session ids, then it is a problem regardless of where
security is enforced. And I don't see how would you be able to hijack AS
session ids, because they will be encrypted in HTTPS.

--
==================================================
Mosha Pasumansky - http://www.mosha.com/msolap
Development Lead in the Analysis Server team
All you need is love (John Lennon)
Disclaimer : This posting is provided "AS IS" with no warranties, and
confers no rights.
==================================================

1 ) I did not say that calculated cells won't work for you, but they
won't let you achive something that cell security didn't

A) Cell security is enforced on the client. Using calculated cells,
enforcement is done on the server. Is this correct ? If it's true then i
can achieve what cell security does not.

2 ) I am not clear whether you mean Proclarity's session ids or AS
session ids. If you mean Proclarity session ids, then it is a problem
regardless of where security is enforced. And I don't see how would you
be able to hijack AS
session ids, because they will be encrypted in HTTPS.

B ) Yes, you're right it's also to confused for me. I understand that
using HTTPS between Proclarity and AS will prevent access to private
data on that specific channel. If someone has registered as public to
our site, after authentication, and access Proclarity using Single Sign
On, Proclarity running as an Application server will return only public
values after enforcing in this middle tier the cell security roles. As
the session is authenticated already in Proclarity is the user loggeed
in he able to hijack the information retured from AS to PAS in any way ?
TThat's something i'm not quite sure and i have some dificulties in
telling something difeent to my security team. In fact what they say is
: Even if HTTPS is used in al layers someone that manages to control the
middle tier will be able to access private data as this really crosses
the AS boundaries. So my question is : Using HTTPS between the browser
and the Web server and using HTTPS between the Application Server and AS
and using cell-security, which security risks are really involved of
having a public user (with an AS Public Role) of having access to
private data ?


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

This is not correct. Calculated cells cannot be enforced to be always on
server.

If somebody breaks into middle tier - they will be able to get to the data
of all users who are connected to that middle tier - this is generally true
even when middle tier is not PAS and back end is not AS. And again, it is
not important whether security is enforced on the client or on the server.
And if middle tier is not broken - I don't see additional security risks.

--
==================================================
Mosha Pasumansky - http://www.mosha.com/msolap
Development Lead in the Analysis Server team
All you need is love (John Lennon)
Disclaimer : This posting is provided "AS IS" with no warranties, and
confers no rights.
==================================================
"joao rodrigues" <jhrodrigues (AT) bportugal (DOT) pt> wrote

Thank you very much for your support Mosha.

1 ) This is not correct. Calculated cells cannot be enforced to be
always on server.

I was really convinced that Calculated Cells and Calculated Members were
ALWAYS calculated on the server side (AS) and always returned as such to
the middle tier, but i guess that from your words i was not correct.

2 ) If somebody breaks into middle tier - they will be able to get to
the data of all users who are connected to that middle tier - this is
generally true even when middle tier is not PAS and back end is not AS.

I some cases this migth be true. For example, using SQLSERVER and
defining two windows accounts (1 with Read Permission and another with
write Permission), if someone breaks into the midddle tier, and as you
say, he will be able to get to the data of all users who are connected
to that middle tier. However if connected users are all public then i
think it's possible to say that only Read Permission will be allowed to
SQLSERVER (as no Write Permission is being used in the middle tier) on
that moment. I agree that if a private user is logged in and someone
breaks the middle tier on that moment of course that in this case
private data on SQLSERVER is also compromised. But that means that the
risk of security is minor than the one observed in AS, as in the later
case no security is applied on the server side. In the former case
(SQLSERVER) this only happens if a private user is currenty logged in,
which i think it decreases the security risk.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!