Our Kibana (7.17.1) users would like to share queries (via Discover → Share → Permalinks) with other users that have different roles/spaces assigned. At the moment the target users get just a blank page if they use the permalink URL.
I activated anonymous authentication to enable Public URLs as a try, but the underlying anonymous user in turn needs role(s)/space(s) assigned and I can't add everything there since this would be against our data security policy.
I also tried the built-in role viewer for the anonymous user but this didn't work without an explicit role in addition and "This functionality is in technical preview and may be changed or removed in a future release." and "read access to any index that is not prefixed with a dot" is also against our security policy anyway.
Is it possible somehow else to give users with different roles/spaces access to shared permalinks?
I ended up creating an extra Share space and:
assigned it to all the respective roles and
added all the respective index patterns to it.
The only drawback is that the users have to switch to this space prior to creating a link if they'd like to share it with users of other roles/spaces.
Related
I am trying to create my application with Google app maker and Ineed to create login with different accounts? how can I create a login with different users roles and each user has a specific pages to see
There's a simple way to do this. Please click on the links in my answer below to go to the screenshot I've added for reference.
Go to App Settings -> Security and add roles you would like to create for your app in the space provided.
In a page, you can go to the Property Editor, scroll down to Security and mention who can see this page.
In a model, you can add controls by going to the Security tab and selecting relevant roles for specifying who can create, load, save or delete records for that model.
Finally, to mention which email address goes into which role, you can go to a specific deployment and add the email addresses for each role manually.
Let me know if this helps. Feel free to ask any questions you may have!
This is for Plone 4. It is quite a general problem. I have a form (ploneformgen) that I want anonymous users to see and fill in, but I want to hide it from registered users (i.e., users who have logged in). Similarly, I have a "log in" link in the navigation menu. Obviously, anonymous users should see that, but logged-in users shouldn't have to see it. I've tried many options which I won't detail here (workflows, scripts that change local permission settings, etc.) since none of them have worked. There must be a standard way of doing this, but I can't work out what it is.
Any ideas?
Untested, but it might work: Products.AutoRole can assign groups and roles to visitors based on their IP, without creating user accounts for them. It also has a switch to only give automatic roles/groups to anonymous users. A rule 255.255.255.255/0 should match all IPs, so all anonymous users get a group, and you can make the form private and visible to that group.
(Note that AutoRole is not IPv6-ready, though, and has caveats regarding user inheritance, particularly: it will de facto disable the admin account, so you should not activate it in your Plone instance, but in the Zope server acl_users, if at all possible.)
Another untested idea.
There's a not a very know product and I never used it in a production environment (but in my tests it works perfectly): collective.subtractiveworkflow (https://pypi.python.org/pypi/collective.subtractiveworkflow) and the use of workflow chain.
In practice you can design a second workflow where View permission will be subtracted from Member roles.
To be honest I'm not 100% sure of how this can work with Anonymous, just because normally you can't define permission for Anon users but not given to other roles. This can be the same in that situation.
I have one requirement like I want to hide the data (lists/libraries/documents) to the users which are forms based authenticated. Windows users can add the data into sharepoint lists. Forms based authenticated users only able to see when ever windows authenticated users give the permission. I thought to create one group for the forms based authentication, but we cannot hide data from them, so this will not work. How to do this ? I am thinking on this, but not able to find the solution.
Any one has any idea?
New Addition:
Actually, there should be two urls (say URL1, URL2) for the same site which we can configure in the alternate access mapping. Only one url (URL2) should be exposed to external users. So, when ever any external user login(Forms user) then we have to show the content which is given access by windows authenticated user. Means when windows users add some content to the URL1 and the give permission for the form authentication users then that content should appear in URL2. By default the content added in the URL1 will be reflected to URL2. But here it should not happen.
Principally, there shouldn't be a problem duplicating your site, and modifying the copy to be more limited than the original.
If both sites are on the same site collection, you can configure them to use the same lists/document libraries.
After you do that, it's simply a matter of configuring AAM to present one site outside, and one inside.
I am using the calendar module with its iCal support for Drupal 6. I have made my event type which appears on the iCal feed. However, I want to make the event content type private, so only authenticated users can read it. By doing this they will not show on the iCal feed. Is there any way that I could get the iCal feed to still show these events?
I agree with calebthorne that normally a feed is public; I can understand the need of making a feed public for a group of users, and not to the anonymous users.
If the feed is created by a view, then you can change the view, and restrict its access to the users you want.
As you can see in the screenshot, you can restrict the access to the users with a particular permission, or to the users with a specific role (authenticated user is one of them).
Hmmm... I would give the Node Access module a look. I use this module to restrict access to content based on content type. I have never tested whether this works in conjunction with the Calendar module but it is worth a shot.
Some more details about the Node Access module (from its project page):
Nodeaccess is a Drupal access control module which provides view, edit and delete access to nodes. Users with the 'grant node permissions' permission will have a grant tab on node pages which allows them to grant access to that node by user or role. Administrators can set default access controls per content type, and also define which roles are available to grant permissions to on the node grants tab.
The upshot is, this module allows you to do things like 'node 123 can be viewed by authenticated users and edited by admin users and joeuser'. As an added bonus, update and delete permissions are separated, so you can make sure users with edit permissions cannot accidentally delete pages.
We want to give users peoplesoft portal access from outside network. But ..that access needs to be read only and very limited.
Has anyone done location based role enabling is peoplesoft.. i.e. disable all roles and enable only particular role based on ip address or web server ?
I have done something similar to that using DNS entries to determine internal/external access. The users wanted to force Self-Service access to all users when they logged into PeopleSoft if they were at home, but give the users full access if they logged in via VPN or at their desk. That way, power users would not have full security unless they were authenticated via VPN or at work.
We accomplished by customizing the USERMAINT component, created a new security table for "self service" security, adding custom Signon PeopleCode, and setting up a 2nd DNS entry that was exposed for external access.
To start, the network admin set up two sets of DNS entries that pointed to the PS web servers. For example, psoft.company.com was the internal DNS and only set for local network access, and selfservice.company.com was the external DNS available for global access.
Next, we customized the USERMAINT component (User Profile). We hid the delivered Roles tab and replaced it with a copy. The new page was pointing to a copy of PSUSERROLE. We did this because we want to use the delivered PSROLEUSER table as the "current" security table. If the Security Admin wants to update a users internal (or day-job) security, we want to store if for long term. (This will make more sense below). So the new custom table, say XXROLEUSER, is now the master table for security.
Then, we added record/page/component for the Security Admin to define "self service" security (XXSSROLES). This record/page just stores Role Names for when users log in externally. This allows the Security Admin to update self service security for seasonal changes, like Open Enrollment. The admin can add a role during Open Enrollment to grant additional access, and then remove it when the period has ended.
Last, we created a custom Signon PeopleCode step that handles the internal/external security switch. The Signon PeopleCode grabs the URL used to log in. The code parses the URL to see with DNS entry was used to access the system. If the DNS entry is "selfservice.company.com", the code will clear our the rows in PSROLEUSER for the user and insert the roles from the XXSSROLES table. If the DNS entry is "psoft.company.com", the code will clear out PSROLEUSER and insert the roles form the XXROLEUSER table.
This code change turns PSROLEUSER into a transaction table. Because the Tools system relies on this table for many different security functions, it is important to create a copy to use as the "master table" for use in the User Profile component.
If this is something you are interested in trying, I'd be happy to post some sample code for the Signon PeopleCode.
I uploaded the Signon PeopleCode function to GitHub (see link below). You can create a custom record to store the PeopleCode and then add it into the Signon PeopleCode page. If you need more information, let me know. I am not able to post the entire tech spec, but I'd be happy to help if you have questions.
http://github.com/iversond/PeopleTools-Dynamic-Login
Recruiting Solutions uses a similar process - when creating the external Candidate Gateway to allow applicants to apply for positions, a 'guest' ID is created for a particular web server that has severely restricted permissions - basically just the external applicant apply objects.
In PS 9 , have a look at PeopleTools > Web Profile > Web Profile Configuration under the security tab. You can definitely secure the system at a web server level.
HTH
Disclaimer: I work for the company.
A bit late to the party, but a useful answer: IntraSee has developed a solution for this exact situation.
The key is that you need to be able to define rules (locations) and then tie those to specific roles. Evaluated at login, the roles are revoked or granted depending on the rules and user location. It can use IP or other attributes to determine roles.
To do this manually is slightly tricky as you need to account for the versioning of the user profile and associated permissions. Signon PeopleCode is the best place to evaluate these rules as you can do it once per session, and you ahve access to the business data to make correlative decisions. E.G. if a person has a huge approval limit, maybe they can't approve remotely, but someone with a small limit can. Same security access, but add or revoked based on location and data.
To your specific case: you would have base roles with read only access to those users, then a set of 'opt-in' roles that gave read/write. When they come in from the correct location, they get the read/write. So, we are only adding the extra access when appropriate.
I would create a separate site ( like the candidate gateway suggestion ), it will need a similar web profile as the one you are currently using, no other changes would be necessary.
Next create a custom menu, then attach all of the components you wish to make read-only.
Register the content references for those custom_menu.components.
Create Roles and Permission Lists adding the custom_menu.components then select "Display Only". Then assign the roles to the users.
Expose that site via the firewall.
That's it.