Is securityTrimming and role based security currently supported in the public view In 15.0.3.2025? What is ASI's direction on this... If the roles are supported is there a way to create roles and assign them to large groups... or plans for default groups like Member - based on the record type being a "Member"?
SiteMapNode role based security and SecurityTrimming - Public View
Suggestions for automatic creation of security roles
I've made some suggestions to what we think would be helpful for automatic roles (or a way to configure what roles should be automatic) Yes it has been submitted in an SMR (177409) Just curious if what other would find helpful in automatic roles or a way to configure the automatic roles so that customers can have tools to make there own choices.
Also just a recommendation or wish... as far as some configuration options to allow for default security roles to be setup and users assgined automatically... is seems that if any product could be specified or configured as a security role (dues, event, order, donation) with some time frame (within the last year or 6 month) to automatically add someone to a security role - and then remove them at the appropiate time. Committee's could be configured the same way...
If we could also have this type of automatic security group by by groups (committee groups) or categories (dues type, product category) ect that would be great.
One the time frame is over... if we could give then a second role like Past_ whatever product or group was...
This would give a tremendous amount of flexiblity to be able to give these groups access to forums, special web content, community groups....
Thanks for the input,
Thanks for the input, Derrick. I will say that Groups are going to be a mainstay of our security going forward, and in a much more dynamic way than it has been. For example, one thing we're discussing is that when someone registers for an event, they would automatically be included in a specific Group (this would be an always on, infrastructure sort of thing). That group would then obviously be available for security as well as other usages (sending out notification, community tools like forums, etc etc). The idea can be extended almost indefinitely (users who have purchased a specific product, for example, might comprise yet another group), and gives a lot of flexibility.
While I can't make any guarantees, my understanding is that this is a major architectural underpinning of iMIS in the future.
public users no entry in UserMain - ASI Master page securitytrim
Ok running into 2 problems....
It's easy to identify the rolekey and the public user from contractmain.contactkey but these are puplic users so they are not in the usermain table --- so trying to add an entry in userrole for them results in a foreign key contraint. It would require adding them to the usermain (which right now is for Full or Casual users). I've not tested doing this yet but would assume that there would be some kind of issue with doing this... would love some input on this...
I would proceed with testing the above but that brings us to the second part of the problem... I'm looking for the public view to then handle the role via standard ASP.net functionality with securityTrimmingEnabled.
It looks like there's code in the master page where ASI is overriding the standard way that ASP would bind a sitemap to a menu... there's not code in there that would handle the security trimming.
We have not been able to get security trimming to work using the sysadmin role. In fact it only hides the item from someone not logged in...once anyone logs in they have access to that item.
So it is looking like our only option at this point is to customize both sides the database & the public view... to build a similar table to UserRole for the public users and then customize the public view to actually work with these roles.
Sorry Derrick, you are
Sorry Derrick, you are correct -- UserRole requires the user to be in UserMain, and you don't want to do this (it makes them a staff user). 15.1 will correct this (all users will be in UserMain, regardless of type, and can be assigned roles etc).
I've not looked at the master page for the public view, you could be correct that there is code in there that ignores the security trimming. Customizing the database and public view is probably your only solution until 15.1 and Web Content Management are available.
Security Roles & Security Groups in 15.1.1.3064
Eric I'm trying to understand what improvements have been made in the 15.1 GA release in these 2 areas -- database & website.
In the database.... I see that the security roles can be manually assigned to all users now (not just the staff users) by using the user credentials or by System Setup > Security Administration > users (which also takes you to user credentials to assign the role). This is good, but it still only allows you to set roles on a person by person basis in the desktop. I am not seeing any method to automate criteria for the role assignment to mass groups of people (at least not without a SQL Script hitting inserting into the usermain & other tables directly). The security admisitration only allows the creation of new security roles not new security groups -- althought I see that a new all members group has been added. I was really hoping to see some supported method to assign a group of people - committee assignments, Dues products (subscriptions or special interest groups), event participation, product purchase or donation as options to grant a role or group.
Website...
The Public View -- looks like the security trimming is turned on by default now and uses the roles but not anything further. Is that correct?
WCM pages allows you to user preconfigured security sets or to set security to roles, groups, users or memeber types. You select access based on the security roles so once someone has the role (manually assigned) they can get access to the specific pages. The only automatic here would be the group - all members or a specific member type. I don't see committee assignments, Dues products (subscriptions or special interest groups), event participation, product purchase or donation as options to grant access to content here either.
Am I missing anything in the GA release of 15.1 or does this sum up what the access and security configuration looks like?
Derrick, your summary is
Derrick, your summary is correct. When I mentioned that we were discussing automatic groups for things like events/dues products/etc, I did not mean to imply that those things would be in 15.1; the only new addition in 15.1 is the All Members and the Member Type groups, as you noted.
However, if automatic groups based on other criteria are important to you, I would encourage you to submit RSEs (and talk to our product management directly as well) regarding that; if PM agrees that such a feature would be valuable, it could be implemented sooner rather than later.
In the meantime, you could set up your own database triggers to maintain automatic groups, using the Member Types groups as a template for how to do so.
RSE's already submitted... thanks for the clarification
I've submitted the RSE's already... and will keep advocating for this functionality.
Thanks for the update.
It's disabled by default (I
It's disabled by default (I don't know why), but you should be able to enable security trimming in web.config and have it work. I don't know if it's officially supported, however.
To add a role to iMIS, go to System Setup > Security > Roles. To add users to that role, go to System Setup > Security > Users and select the user you wish to add.
To add en mass you'll need to get down in the SQL; it's not terribly complicated, just locate the entry in UserMain for that user and get the UserKey. Then locate the entry in RoleMain for the role you created and get the RoleKey. Insert the UserKey and RoleKey into UserRole.
Regarding automatically adding users to groups; this will be partially implemented in 15.1 (the specific scenario you mentioned -- adding users to a Member default group, in addition to having automatic groups for all Member Types -- is supported). There is no plan to do so in earlier versions that I know of.