I have been tasked with something that seems a challenge in the security world. The problem is to build a website that has:
Complex ACLs and view permissions. eg. A customer's transaction history should only be displayed in a portal for the customer support agents.
Multi-branded. eg. If the customer support agent is Microsoft then they should have access only to that subset of users and to have the site look'n'feel match their brand. If the agent is Apple then do likewise with their customers and brand.
Item #1 is standard security. Item #2 (multi-branding) seems to overcomplicate things.
To meet the above requirements it seems that each portal and access request will need to take into account things such as: brand being viewed, user roles, objects and their membership to a given brand.
How do I go about tackling the above? Is there any literature on how to build a secure, multi-branded site?
Related
I would like to be able to supply external users (customers, potential leads, suppliers) across organisations and internal users inside my organisation with documents.
The documents should be organisable per user individually. E.g. Customer A should be able too see documents for the product he bought, not more and not less documents.
No further functionality is currently needed besides that.
Is SharePoint the right tool for that job?
If not what other tools can you recommend from your experience?
I see you tagged SharePoint 2019, I'd advise against using on-prem SharePoint for Sharing documents externally. It is possible, but to do it securely is complex and expensive.
O365 on the other hand is pretty simple and the security is already implemented for you. You can determine the level of access that your external users have and you can extend that by using additional tools provided by Microsoft Information Protection.
You can secure access by forcing guests to login or simply have anonymous links. To add to that you can automate your publishing processes using Power Automate, the O365 workflow.
Take out a trial subscription and make sure it meets all your requirements first.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
I recently entertained the idea of developing an app that aggregates Instagram data of a small community and displays it in different UI clusters, derived by certain analytics. While the API provides all the required endpoints for my requirements, I started re-inventing the app over and over again, to satisfy the Instagram platform policy, terms and conditions as well as the login permissions for the different scopes.
According to Instagram API documentation there are 3 categories for the scopes of all apps:
To help individuals share their own content with 3rd party apps: basic
This use case is meant for apps that allow the general public to login with Instagram to get their own content; for example, an app that allows people to print their own pictures. Apps that fall into this use case will only have access to the basic permission.
To help brands and advertisers understand and manage their audience and digital media rights: basic, public_content, comments, relationships, likes, follower_list
This use case is meant for products that don't have a public facing login integration, but are gated to brands and advertisers. The product must support either multiple brands and advertisers (e.g. a social media management platform) or multiple users within a single brand or advertiser organisation.
To help broadcasters and publishers discover content, get digital rights to media, and share media with proper attribution: basic, public_content, comments
This use case is meant for products that don't have a public facing login integration, but are gated to broadcasters and publishers. The product must support either multiple broadcasters and publishers, or multiple users within a single broadcasters or publisher organization.
Ideally, my app would benefit as many analytical endpoints as possible, particularly if I can process the list of followers and public content. This means my app should fall under group (2). However, the target community of this app was not consisted of brands and advertisers. Group (3) is also not an option, since my community is consisted of individuals. Then I was thinking that group (1) will fit my needs. But that was also not the case, since according to platform policy, I won't be allowed to put the media in different UI clusters:
You cannot replicate the core user experience of the Instagram apps or web site. For example, do not build a media viewer.
Then I started comparing the use cases with existing live apps. I noticed that if they would carefully follow the terms and conditions, as well as platform policies, they would also be unfit for all rules imposed by Instagram. Let me provide examples:
minter.io (broadcasters == individuals?)
minter.io focuses on Instagram analytics. Thus, it falls in group (2). However, anyone can register on this system, meaning any individual that owns an Instagram account. How is this a valid case when brands and advertisers are not gated? Furthermore, even if those are somehow filtered in some future phase (which they claim they do manually), why is it allowed to generate a report of a "competitor" account, when the ID of that account could be any individual, and not an advertiser?
pikore.com (discover / search function?)
Apart from having the similar issues of minter.io, where everyone can login, I fail to understand how is it possible for pikore.com to provide a "discover" functionality which is exactly what Instagram offers on its mobile apps? Is that not breach of platform policy? Or the fact that it is also able to display all media items of a given account mixed with advertisement? For example: pikore.com/arianagrande. This breaches also other terms stated in General Terms of Platform Policy:
24. Add something unique to the community. Don't use the Instagram APIs to replicate or attempt to replace the functionality or essential user experiences of Instagram.com or any of Instagram's apps.
25. Respect the way Instagram looks and functions. Don't offer experiences that change it.
26. Don't attempt to build an ad network on Instagram.
ElseWatcher (another media viewer?)
I absolutely adore this app. But the fact that the Instagram data is organized by location and date, it seems to me that it's another media viewer with extra functionalities.
socialbakers.com (free social tracker?)
socialbakers.com, while providing an amazing interface, it requests public_content scope for any individual user of instagram.com. On top of that, without providing any mechanism to gate the broadcasters, offers their services as "Free Instagram Analytics Tool".
Maybe I am wrong, but the way I see it, the Instagram API rules, are not applied consistently to all 3rd party apps. Can anyone explain whether those are inconsistencies indeed, or whether I got things the wrong way?
While at it, I would also like to know how is it possible to have the term clause "1. Instagram users own their media (stated here) in conjunction with "17. Don't apply computer vision technology to User Content, without our prior permission" (stated here). Does that mean that if I am an Instagram API user that agrees to these terms, and I perform computer vision on any image that also happens to be on Instagram, that I am breaching terms?
Have you seen this cases?
simplymeasured.com/freebies/instagram-analytics
pro.iconosquare.com/pricing
websta.me
unionmetrics.com/free-tools/instagram-account-checkup/
After June 1st all Instagram 3rd party apps should pass a review. The review should contain video screencast with
Provide a link to a video screencast showing the experience in your
app. Please show how your integration uses all permissions you are
requesting, any interface to moderate content or getting rights to
media, and any Instagram login experience. Since your app may be in
sandbox mode, you can use data from sandbox users to showcase the
integration.
I think, Instagram wouldn't have approved any app which violate their rules.
We are implementing a Liferay 6. 2 solution, everything was set but then we had a problem. Thing is, we are importing all the users from AD using LDAP with their group information. So, in liferay, we will have users and users' group. We planned to follow organization->sub-organization structure but the customer does not want to assign all the users(no option to assign user groups to organization which i know why and it totally make sense ) to the organization manually which, kind of, makes sense. So, then we had to change our design, now what we are doing is actually creating a department-wise site then assigning user groups to the site and then linking site to organization. So two questions.
Does it make any sense to have organization? if so then what advantages will I have in this particular case.
Do you see any drawbacks in our approach or should we follow a better approach which we are not aware of.
This is linked to this question which seems to have asked a while back. Security implementation in a project that is adhering to basic principles of Domain driven design. let me give an example
Banking System:
Use Case: A new bank deposit is being made and requires approval as it is first deposit
a. Clerk can auto authorize if the deposit amount is <5000
b. Manager can be of two types - Bank manager / Account Manager. ONLY Account manager can authorize any accounts that have deposit >5000
My concerns are as follows (Pls correct if the concern itself is correct)
Not sure where should i build this following logic - takes care of checking whether the logged on user has authorization to do certain things taking in to account his title - (this case Account manager). Authorizing is a use case, but the security layer seems to have intimate knowledge on the domain object
In general Authorization (not authentication). I know that Role Based authentication would help, but the question is "where" - in which layer and the call flow. Should the UI layer call on some security layer or would the domain layer validate itself for all possible combinations ?
Please help. Its very confusing.
Bump to see if this gets experts notice
Cheers
Security is a cross-cutting design feature which can affect all classes, methods and properties.
From a DDD perspective you would go with specifications and roles.
Where and how those specifications get implemented comes down to your architecture. You could go with aspects, you could go with in-line calls, events, etc.
Here are some links I would check out regarding security and roles:
Security
Roles
RBAC
In Moss 2007 you have the ability to set the target audience for each individual web part within a page. Is there a way to preview how the page will look to another user without logging in as that user? What I am looking for is a way for someone with full control/design permissions on a site to be able to preview how the site will be displayed to another user. Any suggestions?
I have a few test accounts that our IS department uses to preview pages, however we do not allow non-IS departamental staff to use those accounts. Those staff members only have access to their one account. So, if a user makes changes the target audience on a web part on one of their pages, right now they have no way to preview how the page will look to someone else other than asking someone else to login & watching over their shoulder. I can't give out the account information for the test accounts, nor can I create new test accounts.
Thanks!
Edit: I have the ability to preview. The problem is that other users with full control of a site can't preview the page. Here's a scenarios: In my school division each school has a site. The principal has full control of his school's site. On the landing page, he wants all the school announcements to be visible. However, some should only be visible to teaching staff, while others need to be visible to the students. He uses audience targetting but cannot preview to see at a glance that the targetting is correct. A lot of the users are not computer savy so things need to be as simple as possible. Also, that was just one scenario, there are other scenarios that are not divided by school. There are many users with full control of a site with different requirements - so it's not feasible to create test accounts for all scenarios.
First I don't think it is possible to have a preview feature if you are using NT security. Maybe it is something you can do with forms authentication but I never used it.
On that subject. I think when you are developing new features or integrating stuff on a MOSS/WSS server you need a little flexibility.
With what I see you have to following things you can do. It is surely more cost effective than developing a custom solution. I assume you are using NT Security.
User accounts : Ask your domain administrator to have dedicated user accounts to play with.
Virtual Machines : Ask to have some virual machines to be able to play with that server combined with tests accounts
Sandboxed environment : Ask your IT dept to create a sandboxed MOSS environment to have to possibility to replicate your actual MOSS environment and create custom user scenarios.
Edit: After re-reading the question I released that you want the users to be able to preview a page. I think you will need to look into writing a preview control that uses Impersonation to load the page. Not sure how feasible this is, but surely someone has created a preview feature. Sounds like a pretty common scenario to me.
Old Answer:
Could you not fire up a non MS browser such as Firefox, which will prompt for the username and password.
You can then just clear the session cookies to be prompted to log in as someone else.
This is the technique I used for an ASP.Net site that used authentication against the domain in a similar manner to SharePoint.
Alternatively, you can create a control/webpart that hooks into the audiences for the site and displays the audience membership to the user (maybe from the GetMembership call). This does not preview the site, but it will give your editors a heads up on who is in each audience. Something that will help them get the audiences correct.
We have made a similar webpart for security group membership.
I think there are two approaches you can take:
Do make use of test accounts to preview the pages. You can ease the "pain" to log in as another user by making use of the RUNAS command (http://technet.microsoft.com/en-us/library/bb490994.aspx). So it's possible to just create a shortcut on the desktop that opens a browser making use of another account's credentials. Only that browser instance will work with the test account.
Make a copy (or more copies) of the page that you want to preview, store it in a secured site (so it's only accessible for the principal for example), and tweak the Audience Targetting properties of the web parts on that page/pages.
For previewing target audiences only, the only way to do it is to create a target audience that runs based on a properties in the SSP User Profile Properties.
You can then have a control that allows the editor to change the value stored thier profile, re-compile the profiles and voila (for some description of voila) the user will have change thier audience targetting values to something else.
This would need quite a bit of coding and some thought put into the rules for the audience targetting.
At the end of the day, the most cost effective way is to push back to your infrastructure guys for an account solution that will allow you to have an "reader" account people can use for this function.