Am working on spartacus, I have a CMSLinkComponent which is having restrictions with user group, lets take admingroup, when i try to impersonate the user who is having admingroup, am unable to see the CMSLinkComponent. I heard that this is an limitation in the spartacus(https://sap.github.io/spartacus-docs/asm/)
Is there any other way to achieve this in spartacus.
As you correctly point out, it is not possible for the AS Agent to apply the customer restriction rules for CMS when impersonating a customer.
The CMS will react according to the authenticated user. In the case of ASM impersonation, the user is the Assisted Service Agent.
As a workaround, perhaps you can evaluate if it is worth giving the AS Agent some additional groups if it makes sense for your use case (and if it even works as intended with the CMS). But there are downsides to this. During customer impersonation, the CMS will always behave according to the CS Agent's groups, regardless or which customer is impersonated.
How do companies like Facebook and Google implement privacy controls at scale? For example, Facebook has a select audience type which includes public,friends, "friends except...", only me, specific friends, and even custom. From an implementation and design standpoint, how do these companies handle this? Are they defining rule bases access controls, are they manually coding in these features, do they have a privacy model they use, or is it a hybrid approach? If anyone has links to public available design docs, conference links, white papers, and even research papers, please feel free to share. Every time I try to search for how company "X" does privacy controls, I get the "Business" talk on privacy or access controls as it relates to data centers which is not what I'm looking for.
In this patent of Google they describe a "User privacy framework" which does all the things you mentioned.
It uses a database which stores rules and privacy levels for each user.
A authorization server manages this database and evaluates requests for user data.
If user A wants to access data of user B, the authorization server checks if the request is allowed or violates rules or privacy levels.
The request is then answered or rejected.
See this flow chart from the patent:
Flow chart (Sorry, I am not allowed to post images yet)
So what are privacy levels and privacy rules?
Rules are conditions which need to be met if a user requests information of another user. I couldn't find an example in the patent, but I suspect a rule could be something like "Is user A blocked by user B?".
Privacy levels seem to be more general than rules. For example the level "semi-public" allows another user to access the requested information if no rule forbids it.
The level "private" allows storage of the information on the authorization server but forbids access of it through other users.
The level "no access" forbids even the storage of the information on the authorization server.
Obviously I have no idea if they really use this on the large-scale. But it is certainly a possible implementation and for me it seems plausible to do it with databases and rule sets.
Hope this helps. Maybe you find even more patents which describe similar frameworks.
I've read about security best practices saying that inactive user accounts should be disabled and even deleted to avoid security issues like unauthorized use. I can see that being true for regular username and password authentication sites, however my application was built to work only with Facebook groups and as such the only way to login or create a new account is to use the Facebook login.
The argument can be said that someone malicious could take control of one of my users' Facebook accounts and then use it access my application. Although that is true if they have control of a Facebook account my application would never know it's a malicious person so I don't see that as a valid criteria to use in determining if the account should be disabled.
Furthermore if a user is inactive and wants to become active again since it's Facebook login there really is no reason for them to go through some kind of reactivation process like confirming their email or changing their password.
I must be missing something here because it's certainly mentioned as a best practice to disable accounts but since my only login method is Facebook (OAuth) I can't come up with a valid reason to disable/delete inactive accounts.
Regarding other methods of unauthorized access I have security measures in place so I'd like to keep the answers relevant to the login method.
Please enlighten me if I've missed something.
If you have decided that your application needs to use Facebook authentication, then your system's identities will only be as traceable as Facebook's identity management permits. (And don't expect Facebook to help you by disabling / blocking users at their end ...)
You need to design it accordingly:
Don't make any assumptions that users will behave properly.
Don't rely on login controls to keep out malicious users.
Put in your own (sufficient) defenses against malicious behavior into your own system.
You are correct that disabling an account in your system won't achieve much if you also allow the user to (easily) reenable it. Given that it is easy to create (effectively) untraceable Facebook accounts, the chances are that a typical malicious actor will not just rely on old accounts. They may use a brand new account and connect from an IP address that you have never seen.
There are some things that you could do though. For example, implement mechanisms to do the following:
Make sure that users simply cannot upload dangerous content (e.g. files with trojans, web content with dangerous links or scripts.
Allow administrative locking an existing account or OAuth identity,
Allow blocking of creation of accounts or access in from specified IP addresses or ranges,
Keep an audit trail so that you can watch the history of user behavior.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'd like to know what people consider best practice for securing the Admin sections of websites, specifically from an authentication/access point of view.
Of course there are obvious things, such as using SSL and logging all access, but I'm wondering just where above these basic steps people consider the bar to be set.
For example:
Are you just relying on the same authentication mechanism that you use for normal users? If not, what?
Are you running the Admin section in the same 'application domain'?
What steps do you take to make the admin section undiscovered? (or do you reject the whole 'obscurity' thing)
So far, suggestions from answerers include:
Introduce an artificial server-side pause into each admin password check to prevent brute force attacks [Developer Art]
Use separate login pages for users and admin using the same DB table (to stop XSRF and session-stealing granting access to admin areas) [Thief Master]
Consider also adding webserver native authentication to the admin area (e.g. via .htaccess) [Thief Master]
Consider blocking users IP after a number of failed admin login attempts [Thief Master]
Add captcha after failed admin login attempts [Thief Master]
Provide equally strong mechanisms (using the above techniques) for users as well as admins (e.g. don't treat admins specially) [Lo'oris]
Consider Second level authentication (e.g. client certificates, smart cards, cardspace, etc.) [JoeGeeky]
Only allow access from trusted IPs/Domains, add check to basic HTTP pipeline (via e.g. HttpModules) if possible. [JoeGeeky]
[ASP.NET] Lock down IPrincipal & Principal (make them immutable and non-enumerable) [JoeGeeky]
Federate Rights Elevation - e.g. email other admins when any admin's rights are upgraded.
[JoeGeeky]
Consider fine-grained rights for admins - e.g. rather than roles based rights, define rights for indicidual actions per admin [JoeGeeky]
Restrict creation of admins - e.g. Admins cannot change or create other admin accounts. Use a locked-down 'superadmin' client for this. [JoeGeeky]
Consider Client Side SSL Certificates, or RSA type keyfobs (electronic tokens) [Daniel Papasian]
If using cookies for Authentication, use separate cookies for admin and normal pages, by e.g. putting the admin section on a different domain. [Daniel Papasian]
If practical, consider keeping the admin site on a private subnet, off the public internet. [John Hartsock]
Reissue auth/session tickets when moving between admin/normal usage contexts of the website [Richard JP Le Guen]
These are all good answers... I generally like to add a couple additional layers for my administrative sections. Although I've used a few variations on a theme, they generally include one of the following:
Second level authentication: This could include client certificates (Ex. x509 certs), smart cards, cardspace, etc...
Domain/IP restrictions: In this case, only clients coming from trusted/verifiable domains; such as internal subnets; are allowed into the admin area. Remote admins often go through trusted VPN entrypoints so their session would be verifiable and is often protected with RSA keys as well. If you're using ASP.NET you can easily perform these checks in the HTTP Pipeline via HTTP Modules which will prevent your application from ever receiving any requests if security checks are not satisfied.
Locked down IPrincipal & Principal-based Authorization: Creating custom Principles is a common practice, although a common mistake is making them modifiable and/or rights enumerable. Although its not just an admin issue, it's more important since here is where users are likely to have elevated rights. Be sure they're immutable and not enumerable. Additionally, make sure all assessments for Authorization are made based on the Principal.
Federate Rights Elevation: When any account receives a select number of rights, all the admins and the security officer are immediately notified via email. This makes sure that if an attacker elevates rights we know right away. These rights generally revolve around priviledged rights, rights to see privacy protected information, and/or financial information (e.g. credit cards).
Issue rights sparingly, even to Admins: Finally, and this can be a bit more advanced for some shops. Authorization rights should be as discreet as possible and should surround real functional behaviours. Typical Role-Based Security (RBS) approaches tend to have a Group mentality. From a security perspective this is not the best pattern. Instead of 'Groups' like 'User Manager', try breaking it down further (Ex. Create User, Authorize User, Elevate/Revoke access rights, etc...). This can have a little more overhead in terms of administration, but this gives you the flexibility to only assign rights that are actually needed by the larger admin group. If access is compromised at least they may not get all rights. I like to wrap this in Code Access Security (CAS) permissions supported by .NET and Java, but that is beyond the scope of this answer. One more thing... in one app, admins cannot manage change other admin accounts, or make a users an admin. That can only be done via a locked down client which only a couple people can access.
If the website requires a login for both regular activities and admins, e.g. a forum, I'd use separate logins which use the same user database. This ensures that XSRF and session-stealing won't allow the attacker to access administrative areas.
Additionally, if the admin section is in a separate subdirectory, securing that one with the webserver's authentication (.htaccess in Apache for example) might be a good idea - then someone needs both that password and the user password.
Obscuring the admin path yields almost no security gain - if someone knows valid login data he's most likely also able to find out the path of the admin tool since he either phished it or keylogged you or got it via social engineering (which would probably reveal the path, too).
A brute-force protection like blocking the user's IP after 3 failed logins or requiring a CAPTCHA after a failed login (not for the first login as that's just extremely annoying for legit users) might also be useful.
I reject obscurity
Using two authentication systems instead of one is overkill
The artificial pause between attempts should be done for users too
Blocking IPs of failed attempts should be done for users too
Strong passwords should be used by users too
If you consider captchas ok, guess what, you could use them for users too
Yes, after writing it, I realize that this answer could be summarized as a "nothing special for the admin login, they are all security features that should be used for any login".
If you do use only a single login for users who have both normal-user privileges and admin privileges, regenerate their session identifier (be it in a cookie or a GET parameter or whatever...) when there is a change in the level of priviledge... at the very least.
So if I log in, do a bunch of normal user stuff and then visit an admin page, regenerate my session ID. If I then navigate away from an admin page(s) to a normal user page, regenerate my ID again.
Have a good admin password.
Not "123456" but a sequence of letters, digits and special characters long enough, say, 15-20 characters. Like "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".
Add a pause for each password check to prevent brute force attack.
Here are some other things to consider:
One option to consider, especially if you manage the admin's computers or they are technically competent, is to use something based on SSL certificates for client authentication. RSA keyfobs and whatnot can also be used for added security.
If you're using cookies at all - perhaps for an authentication/session token - you probably want to ensure that the cookies are only sent to the admin pages. This helps mitigate the risks posed to your site by stealing cookies, by either layer 1/2 compromise or XSS. This can be done easily by having the admin portion being on a different hostname or domain as well as setting the secure flag with the cookie.
Restricting by IP can be smart as well, and if you have users throughout the internet you can still do this, if there is a trusted VPN that they can join.
We use Windows Authentication for admin access. This is most practical way of protecting admin areas while keeping the authentication seperate from what applies to general end-users. The system admin manages the Admin user access credentials and enforces password policies on the domain user account.
The strict way is to have two complete different "farms" including databases, servers and all and move the data from one farm to the other. Most modern, large scale, systems use this approach (Vignette, SharePoint, etc.). It's normally refered to as having different stages "editing stage" -> "preview stage" -> "delivery stage". This method lets you treat content/config the same way you treat code (dev->qa->prod).
If you are less paranoid you can have a single database but only have your admin section available on the "editing" servers. I mean, only have the editing scripts/files placed on the editing server.
Naturally the editing stage should only be available on a local intranet and/or using a VPN.
This may seem a bit of an overkill and may not be the easiest solution for all usage cases, but it is definetly the most robust way of doing things.
Note that things like "have strong admin passwords" are nice, but still leave your admin open to smart attacts of all sorts.
It very much depends on what kind of data you want to protect (legal requirements and such).
Alot of suggestions is about authentication.. I think you just should consider using OpenId / Facebook authentication as login. (They will most likely spend more resources on authentication security then you)
Save changes as well as updating values in the database. That way you can rollback changes from user X or between date X and Y.
I didn't notice anyone mention storage/validation of the admin password. Please please please do not store the PW in plain text, and preferably not even something that can be reversed - use something like a salted MD5 hash so that at the very least if someone happens to retrieve the stored "password" they don't have anything terribly useful, unless they also have your salt scheme.
Add a password field and a security question that the Administrator will know, e.g. what was your first girlfriend name, or randomize the questions everytime viewing the admin panel.
Perhaps you could always put the administration section in a big directory, e.g.
http://domain.com/sub/sub/sub/sub/sub/index.php
But that's not really good hah.
Perhaps you could include a query string in the home page, like:
http://domain.com/index.php?display=true
When it does, the username and password field will appear.
I am creating a web-page/website that integrates all my accounts into one spectrum, as in, from this page I want to use this page to log into my mail box online or any other site that requires authentication. All i want is a central login panel. enter my unname&passwd and get redirected to my mail. Is that an impossible question to ask?
It sounds to me like you want to consider using OpenId, which is a standard, fairly widely adopted form of single sign-on. Used by this very site, in fact, and supported by at least two of the three companies you mentioned: yahoo and google. Hotmail does not currently support it.
It completely depends on the individual service. You'll have to investigate each service to see if they even allow you to authenticate against their servers remotely. In the event that they do allow it, it's still up to the service whether or not you'll be able to retrieve any kind of information from them after logging in.
Banks in particular are very unlikely to give you any way to interface with them and the ones that do will likely require a monthly access fee.
You want to look into SAML, an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.
With SAML, you can communicate between the major single sign on (SS0) technologies like CAS, OpenID, Shibboleth, AD/LDAP...