Prev: Open an external file from a formular
Next: Create Desktop Shortcuts
From: Banana on 21 Jan 2010 14:16
David W. Fenton wrote:
> I don't understand why Bob's question is not getting an answer from
> somwhere. Surely somebody among the MVPs somewhere or someone at MS
> knows the answers to his questions, but I'm not seeing anything (and
> he's asked in the Technet 2010 beta newsgroups, too).
>
> Bob is asking about a garden-variety distribution scenario, and it
> seems nobody has given any thought to what to me seems a very
> obvious use case that should already be completely worked out.

Unfortunately, I have no answer to this question, and I do agree that
this should already have been documented/discussed _somewhere_. I can
only say that figuring this out on my own was not an easy task as I had
to learn a new security model, and work out how it correlates to a new
product.

At least I hope others will come and answer and hopefully correct &
point out where I could do better. I'd gladly welcome it. If nothing
else, at least we have a starting point for the discussion & further
analysis.
From: David W. Fenton on 22 Jan 2010 16:59
Banana <Banana(a)Republic.com> wrote in
news:4B58A711.2000105(a)Republic.com:

> David W. Fenton wrote:
>> I'm confused.
>>
>> For plain old SharePoint distribution of your front end (like any
>> other file, i.e., not involving Access services at all), sure,
>> you can upload a secured MDB and the supporting workgroup file
>> and still use Jet ULS.
>>
>> But it's only ACCDB that is compatible with Access services, so
>> there is no security available at all (database passwords are not
>> security).
>>
>> So, I'm having trouble parsing the quote portion of your
>> paragraph above.
>
> Well, I don't consider database passwords to be a real security
> but it doesn't change the fact that some people out there do want
> to secure the file in some way, be it using AD queries to check
> the user's permissions before allowing them to go to a certain
> form,

That's not security, that's just controlling program flow.

> using ACCDE to prevent
> unauthorized editing,

....of Access objects.

> rolling out a DIY security (which I personally
> think is waste of time and fairly risky proposition but again, I'm
> only describing what is being done by others). Anyway, this is
> what I was referring to as 'traditional approaches', which
> certainly couldn't include ULS as you noted- not available in
> ACCDB/ACCDE files.

Other than ACCDE, none of these accomplishes anything worth doing in
regard to SECURITY, in my opinion. Using NTFS user groups for
controlling program flow is sensible, seems to me (AD is not
necessary unless you want to use AD-specific features, such as
organizational units). But it's not SECURITY.

> One more traditional approach was also to make use of Windows
> Filesystem permissions to keep out the non-users- this wouldn't
> certainly apply in context of Sharepoint distributing the file,
> however, I'm fairly sure Sharepoint can be configured to behave in
> similar manner, not allowing nonusers to download the file at all.

I have certainly used Sharepoint servers pre-Office 2007 (i.e., the
simple version that ships with Windows Server 2003), and they
required authentication. But I was always using them from outside
the network, so I wasn't authenticated against the Sharepoint
servers' domain controllers.

I would expect you have builtin Sharepoint user groups when you
install Sharepoint on a machine, and some method for installing
those groups on your domain controller (when your Sharepoint server
is not your domain controller). Of course, I'm assuming things are
done *logically*, but I can't conceive of any other way that they
could be done!

> The point being made is that if you still want to secure the
> hybrid database that is distributed via Sharepoint, the
> traditional approaches still applies for the client objects
> because the Sharepoint security model will only deal with
> Sharepoint objects and client objects aren't subject to
> Sharepoint's security (albeit in an indirect fashion should the
> objects reference Sharepoint objects).

Sure. But I'm not sure that was Bob's question.

> I've yet to find out whether it is possible to tune the Sharepoint
> security to act effectively as RWOP or RunAs so that only the
> application itself has the permissions to update the lists and
> denying the same thing to the users, and that is what I hope to
> find out eventually. As I said, this is only my first attempt at
> understanding the security model and at least it can be nominally
> secured as described in my prior post.

I thought Albert or somebody had said that Sharepoint 2010 security
was majorly enhanced so that it took advantage of the underlying SQL
Server security. Obviously, that applies to data, not to front ends,
but that's a big deal, seems to me.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 22 Jan 2010 17:38
David W. Fenton wrote:
> But it's not SECURITY.

All right. I don't know how you are defining the security. However, many
people would tend to think all those options fall under 'security'
heading, whether this is correct or not.

> I have certainly used Sharepoint servers pre-Office 2007 (i.e., the
> simple version that ships with Windows Server 2003), and they
> required authentication. But I was always using them from outside
> the network, so I wasn't authenticated against the Sharepoint
> servers' domain controllers.

Well, it depends on how Sharepoint is configured. For example,
Sharepoint has 3 different security mechanism to choose from, and
anonymous login can be enabled. For a company I worked with, I always
had to authenticate into Sharepoint 2007, and I am fairly I was using AD
user credential even though I was using Safari & Mac OS X because it was
the same one I used for other resources with the company and my
credentials fits the AD pattern.

In case of web database I published to my Sharepoint, I usually had to
authenticate in same manner, using my AD user I created for myself every
time I visited (and started a new session). This was true whether I did
in the Windows VM or on Mac OS X's Safari. I could enable anonymous user
and not get this prompt, but I've not gotten to that point just yet.

> I would expect you have builtin Sharepoint user groups when you
> install Sharepoint on a machine, and some method for installing
> those groups on your domain controller (when your Sharepoint server
> is not your domain controller). Of course, I'm assuming things are
> done *logically*, but I can't conceive of any other way that they
> could be done!

Again, it depends on what security mechanism was chosen when Sharepoint
was installed. There are Windows Authentication (pretty much like what
we know about SQL Server), ASP.NET Forms authentication, and Web Single
Sign-On. For my server, I used the default, Windows Authentication.

Furthermore, it further depends on whether I allow Sharepoint to
auto-create users or allow anonymous users.

> Sure. But I'm not sure that was Bob's question.

Perhaps, but I was trying to be complete. I hope that is not an error.

> I thought Albert or somebody had said that Sharepoint 2010 security
> was majorly enhanced so that it took advantage of the underlying SQL
> Server security. Obviously, that applies to data, not to front ends,
> but that's a big deal, seems to me.

I don't know about this. I do think it's fairly easy to protect data
(e.g. lists) from non privileged users because this is a server-based
security, rather file-based security which is alwasy going to be
ineffectual. However, as you said, the front-end objects is going to be
more problematic. The simplest solution will be probably in form of not
allowing to download the web database and distribute the rich client
database separately.

From the POV of developing & deploying a web database, security setup
is probably going to be handled by a Sharepoint Administrator. Access
2010 provides a built-in function to interrogate the web client's group
which can be used to "control program flow" and allow them to open only
certain forms, but again, that requires understanding what kind of
security mechanism the particular Sharepoint Server was configured to use.

From: David W. Fenton on 23 Jan 2010 19:35
Banana <Banana(a)Republic.com> wrote in
news:4B5A28C8.7040105(a)Republic.com:

> David W. Fenton wrote:
>> But it's not SECURITY.
>
> All right. I don't know how you are defining the security.
> However, many people would tend to think all those options fall
> under 'security' heading, whether this is correct or not.

Since it's enforced at the program level, while you may be using
NTFS security groups to determine who sees what, it's still not
security. All you're doing is controlling program behavior/flow.

I'm not saying that's not incredibly useful -- I've got lots of apps
out there that use Jet ULS for no purpose other than that (i.e.,
there are no permissions set on anything other than default full
control for everyone), but it's not security. It's just a way of
piggybacking on a security infrastructure's user management
infrastructure to control program flow/behavior.

While the result of that may be that certain users don't see certain
things, it's still not what I'd call security, just a useful form of
obfuscation (i.e., security by obscurity).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 23 Jan 2010 22:14
David W. Fenton wrote:
> While the result of that may be that certain users don't see certain
> things, it's still not what I'd call security, just a useful form of
> obfuscation (i.e., security by obscurity).

I'm having hard time imagining how could it be termed obfuscation
because by using this technique there is no need to store any key or
password and hide it. By designing the application to depend on a
specific domain & members of group (for AD - I've really not had the
occasion to solve this for non-AD context), it cannot be used outside
the domain, or by nonusers within the domain. It may not be 'security'
but it certainly couldn't be obfuscation because there's nothing to
obfuscate unless you want to consider the machine code as obfuscation
needing to be decompiled.

Now, this would be quite useless if the requirement was not to protect
the code but also the data and the data was also stored in the ACCDE
file. In such cases, the proper answer is to move out data into a server
RDBMS, but in terms of protecting code & UI objects, this is an
effective technique. In context of using a web database inside full
Access, however, reduce the utility because of its reliance on macros
which are still editable even in an ACCDE.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Open an external file from a formular
Next: Create Desktop Shortcuts