Re: strange security role issue



Thanks for your reply Jrl,

My pleasure. BTW, If you by any chance receive some feedback form about us,
we'd really appreciate your comments and feedback :)

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we

can improve the support we provide to you. Please feel free to let my
manager know what you think of

the level of service provided. You can send feedback directly to my manager
at: msdnmg@xxxxxxxxxxxxxx

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
References: <HpNAj.64006$w94.13094@pd7urf2no>
<hinc7AmgIHA.5204@xxxxxxxxxxxxxxxxxxxxxx> <cr3Bj.66920$pM4.12946@pd7urf1no>
<WY7ZQTygIHA.4672@xxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <WY7ZQTygIHA.4672@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: strange security role issue


Thanks very much, this cleared up the problem perfectly.
- count me as a 'delighted' customer!

""Steven Cheng"" <stcheng@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:WY7ZQTygIHA.4672@xxxxxxxxxxxxxxxxxxxxxxxxx
Thanks for your reply Jrl,

From the <authorization> setting you provided below:

As for the authorization, here is the setting (from web.config in the
secured folder), for a section that should not be viewable by a new user
(but is) :

============
<authorization>
<allow roles="administrator" />
<deny roles="member" />
<deny roles="client" />
<deny users="?" />
</authorization>
=================

I found one problem( if you want to prevent new created user from viewing
the pages). Yes, a new created user has not roles associated with him.
However, he is a valid user and he is authenticated user(there also
exists
the user rule besides role rules). In your authorization rules, you
add
the following ones:

** allow admin role
** deny member role
** denty client role
** deny unauthenticated user

However, what you've missed here? You haven't deny a normal authenticated
user(and a new created user is just a normal authenticated user if he is
login).

I suggest you change the authorization rules to the following one:

#you only allow admin role here and denty all other users
============
<authorization>
<allow roles="administrator" />
<deny users="*" />
</authorization>
=================

Actually a recommended pattern for authorization rules is first add all
the
roles/users you want to allow, then, add deny everyone in the last rule.

Best regards,

Steven Cheng
Microsoft MSDN Online Support Lead

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we

can improve the support we provide to you. Please feel free to let my
manager know what you think of

the level of service provided. You can send feedback directly to my
manager
at: msdnmg@xxxxxxxxxxxxxx

This posting is provided "AS IS" with no warranties, and confers no
rights.

--------------------


Newsgroups: microsoft.public.vsnet.general
References: <HpNAj.64006$w94.13094@pd7urf2no>
<hinc7AmgIHA.5204@xxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <hinc7AmgIHA.5204@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: strange security role issue


Thanks, your pointer led me to the CreateUserWizard1_CreatedUser hook,
which
will work fine.

As for the authorization, here is the setting (from web.config in the
secured folder), for a section that should not be viewable by a new user
(but is) :

<?xml version="1.0" encoding="utf-8"?>
<configuration
xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0";>
<system.web>
<authorization>
<allow roles="administrator" />
<deny roles="member" />
<deny roles="client" />
<deny users="?" />
</authorization>
</system.web>
</configuration>

When a new user is created, I have confirmed that they are not given any
role. So this authorization rule would not apply, correct? (since a new
user
is now not anonymous, and is not a member of any of the roles listed).

Yet, if this is true, how can I create a rule for any known user that is
not
a member of any role?

The other aspect you mentioned was the sitemap config file, by which I
assume you mean the sitemap section of the web.config file, correct?

I use this setting:

<siteMap defaultProvider="DesktopSiteMap" enabled="true">
<providers>
<add name="DesktopSiteMap" type="System.Web.XmlSiteMapProvider"
siteMapFile="~/desktop/desktop.sitemap" securityTrimmingEnabled="true"/>
<add name="MobileSiteMap" type="System.Web.XmlSiteMapProvider"
siteMapFile="~/mobile/mobile.sitemap" securityTrimmingEnabled="true"/>
</providers>
</siteMap>

I found a reference to adding roles in the sitemap node
(ms-help://MS.VSCC.v90/MS.VSIPCC.v90/MS.MSSDK.1033/MS.NETFX30SDK.1033/dv_
as
pnetcon/html/4028528f-e01c-4ae3-bd8d-bb161718fe61.htm)
where it shows how to allow access to everyone,
<siteMapNode title="Home" description="Home" url="default.aspx"
roles="*">

By adding these access rules explicitly on a node, the article suggests
one
can improve performance. But this seems only to reproduce the
functionality
that security trimming provides, and is not required, correct?

Summary of question at this point is:
if my settings above are correct, do I need to create a special case for
known users that are not assigned to a role? How would I describe that
group
in the authorization section?


""Steven Cheng"" <stcheng@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:hinc7AmgIHA.5204@xxxxxxxxxxxxxxxxxxxxxxxxx
Hi Jrl,

As for the CreateUserWizard, I think you can consider using the
following
means to add the additional task:

The CreateUserWizard control has some events such as "CreatingUser" ,
"CreatedUser". The "CreatedUser" event fires after the user has been
successfully created. Therefore, you can consider doing the email
sending
or other post-tasks there. Also, you can test to see whether the
"Username"
property of the CreateUserWizard is still available there, if not, you
may
need to store the username in "CreatingUser" event or some other
earlier
place

For the security trimming, based on my experience, such
navigation/access
rule mismatch problem is often cased by incorrect role authroization
setting. What's your current <authorization> setting ?

According to the security-trimming reference, there are two things that
will control whether a certain navigation item(node in treeview or item
in
menu) will display to the cerrtain user:

**the url/file authorization rule (can be set through <authorization>
setting)

** the "roles" attribute in sitemap config file

first, ASP.NET will use authorization setting to determine the
visiblility
of a certain node. And if you have "roles" attribute set in
SiteMapNode,
runtime will check it to see whether any extra users are allowed to see
the
certain node(url...).

#ASP.NET Site-Map Security Trimming
http://msdn2.microsoft.com/en-us/library/ms178428.aspx

You can check your application's setting according to the above info to
see
whether there is any rule setting that cause this problem.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments
and
suggestions about how we

can improve the support we provide to you. Please feel free to let my
manager know what you think of

the level of service provided. You can send feedback directly to my
manager
at: msdnmg@xxxxxxxxxxxxxx

==================================================
Get notification to my posts through email? Please refer to



http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent
issues
where an initial response

from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each
follow
up response may take

approximately 2 business days as the support
professional working with you may need further investigation to reach
the
most efficient resolution.

The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump

analysis issues. Issues of this nature are best handled working with a
dedicated Microsoft Support

Engineer by contacting Microsoft Customer Support Services (CSS) at

http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.






--------------------
X-Trace-PostClient-IP: 70.67.40.71
From: "jrl" <jrl@xxxxxxxxxxxxxxxx>
Newsgroups: microsoft.public.vsnet.general
Subject: strange security role issue


I have a (development) website, where I have used role based security,
and
a
sitemap with SecurityTrimingEnabled as True. In this situation, I have
sections of the site which are accessible or not, depending on the
role
a
user is in.

I use the create user wizard to allow an internet visitor to create a
user
account. The wizard works fine, but how can I put an extra little task
into
the wizard's process? I'd like the wizard to send the administrator an
email, to alert that there is a new user, who needs to have the role
set.
(I
can handle the email part, but I don't know where to call this extra
task,
within the wizard's sequence) This is the first part of the question.

The second part, is that I've noticed a strange behavior in the role
that
a
newly created user gets. When I view the new user roles in the Web Site
Administration tool, it says that the user does not belong to any
roles.
This is what I expect. However, when I log in as that new user (with no
roles) I find that I have access to the whole navigation tree. Since
securitytriming is enabled, I should only be able to see areas of the
site
that are visible to all. Instead, I can see areas that are normally
only
visible to the administrator role users. This is obviously very bad!

How can I ensure the role that new users get when the wizard creates
the
user? Is there a step needed to define their role, or why is their
unset
role allowing them to see administrator content?










.



Relevant Pages

  • Re: ComboBox DropDownWidth
    ... Appreciate your feedback. ... Microsoft MSDN Online Support Lead ... Delighting our customers is our #1 priority. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: DIME WSE 2.0 in .NET 2.0
    ... \par Microsoft MSDN Online Support Lead ... We do not have any control over the web services, ... \par support DIME in WSE 3.0? ... \par> Microsoft MSDN Online Support Lead ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: WCF webservice over SSL and without
    ... \par Microsoft MSDN Online Support Lead ... \par Subject: Re: WCF webservice over SSL and without ... this is just https that's the problem... ...
    (microsoft.public.dotnet.framework.webservices)
  • RE: Securing a single aspx page
    ... forms authentication by default will allow everyone access ... authorization setting: ... Microsoft MSDN Online Support Lead ... where an initial response from the community or a Microsoft Support ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Securing a single aspx page
    ... forms authentication by default will allow everyone access ... authorization setting: ... Microsoft MSDN Online Support Lead ... where an initial response from the community or a Microsoft Support ...
    (microsoft.public.dotnet.framework.aspnet)