I have an application where users of my organization, who are not users of this application can register themselves in the first log. When they register, they can choose one or more app's profiles, like contract manager, supervisor etc. These profiles have specific authorization schemes per page, buttons, regions in app. The user must logoff and login again at the inicial log to see these menu's references
Do you know of any way that these menu's references could be viewed/activated in the first of all logs?
The oracle apex version is 5.1.4.
Regards.
I'm answering my own question as follows:
I do a self-criticism for the question because I consider it to have failed to take into account all aspects of information security. Even though I'm always careful about security, a solution of this kind might attend me, considering a IT's well secure work's scenario, but may not be the case for all environments.
I would consider this a valid question for security experts, who could see in the scenario that I proposed, a failure in the APEX environment, in which I have not yet seen.
Related
The "Two Factor" requirement is configured per user. If we have multiple applications, how do we achieve that
for application A (e.g. a webapp) 2FA is required
but for application B (e.g. a native app), for the same user, 2FA is not required (never, not even for the first time it is used)?
I'm aware of the trustComputer attribute but I don't think it helps for this problem.
Two Factor is at the User level in FusionAuth. This is by design since if the user has selected to protect their account, then they should be forced to provide their additional factor regardless of the Application they are logging into.
There isn't currently a way to change this behavior and we would need to understand the use case in detail as well as any security issues with allowing specific Applications to bypass two-factor authentication.
You can open a feature request on the FusionAuth GitHub issue tracker here: https://github.com/FusionAuth/fusionauth-issues if you want. Please provide as much detail about the use case and why some Applications allow two-factor while others don't. This will help the FusionAuth team assess the implications of adding this feature.
I'm trying to design MVC4.5 website on Azure with latest EF but stuck in setting up membership and role base authentication.
I'm somewhat lost in MembershipProvider, SimpleMembershipProvider and ExtendedMembershipProvider.
I found that unlike SqlMembershipProvider the SimplememberShipProvider is not designed to store multiple applications (through ApplicationName and ApplicationID) in a single database and map users accordingly so that business can run multiple applications with only one database.
I hear all praises of SimpleMembershipProvider, my question is how should the database/providers be designed so that I'm able to store user's in association with respective applications in a single database. User registration info must be completely independent from same user name in other application. I also need new features of Open Authentication.
Broadly, my queries are:
Is it possible to use SimpleMmebershipProvider to differentiate between multiple applications in a single database.
I'm thinking to modify existing schema structure made by SimpleMembershipProvider to include ApplicationId column , but then how would even a custom provider that is inherited from Extended membership provider add ApplicationId against any user.
Is there any other provider available or any article that would guide in implementing custom membership provider with custom database design along with features of open authentication.
Or am I going with completely wrong approach?
Answering to the queries of BernardG
Do you want a "head" url/site, then redirect users to the proper
application, or
No, sites should not appear related nor will be redirect to other.
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Again no, each application should have it's own registration process. Further two applications can have same username but these accounts would not be related.
Can a user register into any application?
Yes.
If not, how do you limit that?
Not limiting.
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Refering to answer to point 2, if there are 4 applications with one database and a user registers for one application, he must need to register again to have access to other application. Hence for any user the sites must not appear related.
Do you want to duplicate users info into each applications?
As per my understanding of the question a combination of username and email address (considering this combination makes any user account unique) can again be stored against another application even with different profile information.
Actually I'm used to the classic membership approach used in ASP.net 2.0 and I'm missing the application Id column for separation.
If I may, I believe your question has a lot more to do with design and establishing clearly the features you want, rather than a specific membership provider, knowing that you can do about anything you want with SimpleMembership.
My questions, and I believe those are the questions you have to ask yourself before going further, are:
Do you want a "head" url/site, then redirect users to the proper
application, or
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Can a user register into any application?
If not, how do you limit that?
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Do you want to duplicate users info into each applications?
It looks to me that this is all about database(s) design, and analysis, for your real needs. Once that's properly done, the part about membership tables will be easily solved.
I will like to know how does Stackoverflow maintain the additional details of users logging in using open-ids? In my knowledge, the details of these users are stored in the server of google,facebook etc. (The ones whose open id is being used). How then this site is also storing info about user's points, badges, privileges etc.?
Open id Selector, the one being used by Stackoverflow, is a client side javascript library so how is this possible?
Is a separate database created? If yes, how? There is no registration even!
Please provide the details of how this is being done.
When you login, the server checks if you already have an account. If there is no entry (it is the very first login), the server will automatically create a new user and save the openid identifier.
So the next time you login, the row is already there, and Stack Overflow will recognize you. By the way, you can learn the id of your database entry by looking at your profile url.
The JavaScript openid-selector is not involved in any of this. It just is a convenience feature which allows easy selection of an openid provider. All its magic is done before the openid magic takes place.
I know the title is a little off, but it's hard to explain the problem in a short sentence.
I am the administrator of a legacy webapp that lets users create surveys and distribute them to a group of people. We have two kinds of "users".
Authorized licenseholders which does all setup themselves.
Clients who just want to have a survey run, but still need a user (because the webapp has "User" as the top entity in a surveyenvironment.)
Sometimes users in #1 want us to do the setup for them (which we offer to do). This means that we have to login as them.
This is also how we do support: we login as them and then follow them along, guiding them.
Which brings me to my dilemma. Currently our security is below par. But this makes it simple for us to do support. We do want to increase our security, and one thing I have been considering is just doing the normal hashing to DB, however, we need to be able to login as a customer, and if they change their password without telling us, and the password is hashed in the db, we have no way of knowing it.
So I was thinking of some kind of twoway encryption for the passwords. Either that or some kind of master password.
Any suggestions?
(The platform is classic ASP... I said it was legacy...)
Both options you present sound unattractive to me.
A master password is probably even more dangerous than what you are doing right now
Encrypting (instead of hashing) passwords in the database is not good enough either IMO, as it takes only a break-in on your end to get hold of all passwords. They really should be hashed.
I assume the product, being an old legacy app, is impossible (or not economically feasible) to change in a way that administrator accounts can impersonate user accounts, which in my opinion is still the best approach to this in a real-world scenario (not everyone shares that opinion, discussion on the issue here).
How about introducing a second password column (password2) containing a hashed password that you enter? The login process of the app may be easy to tweak into looking in a second column as well. It might be easy to implement, and I can not see any additional security problems coming from it (correct me if I'm wrong of course.)
What I would do is to let the support staff login with their username/password but to chose a user to "impersonate". So in your session you will have:
logged_user - the actual user who typed in his/her username and password
impersonated user - the user (1) is acting on behalf of
Everything you do is done with the impersonated_user's permissions and preferences.
If you are not impersonating anyone impersonated_user=logged_user.
This way you have to always log any operation with both "actual" username and "impersonated" username; for example:
2010-03-09 | 11:34 am | deleted item #890 | 'George' impersonating 'Lizzie'
sounds like you want to decouple your authentication from your identity a bit. Maybe something like an administrator override page, so that after you log in as the administrator, you have a choice of which user identity you wish to assume. After selecting an identity, you continue to use the app without further authentication.
I like the solution offered by Manrico Corazzi. It reminded me that when you need support from Microsoft, there is way to hand over the control of your machine to a technician. That could be another way to achieve the impersonating mechanism. In order for an administrator account to log in, an authorized license-holders would have to explicitly allow him to join his session and act with all his privileges.
The roadmap for OpenSSO said entitlements would be out summer09. Anyone know whether it will be able to solve data level security, for example "userA can only enter <500 in this field on the screen" OR "UserA can see only these values in the dropdown".
How is this implemented in organisations, each app controls the data level security or is there some who have an enterprise repository for it.
Thanks
yes, this is exactly the kind of problem that OpenSSO Entitlements are designed to solve. I did a demo at JavaOne last week that showed a demo mobile phone account management system with three policies:
Each phone user can read their own permissions (e.g. can download music/video) and call log.
The account holder can read and write the permissions of all phones on the account, and can see the call logs for all phones on the account.
The account holder can read and write account-wide data (e.g. billing address).
I'll be posting the source code to the demo and explaining how to deploy it on my blog.
To answer the second part of your question, there is an enterprise repository for policy, but it is enforced on an app-by-app basis. In the demo, most enforcement is done by a servlet filter which makes entitlement calls for each requested URL. This worked well, since we used RESTful web services that express the requested resource in the URL. In one spot we made an explicit policy call since the URL pattern did not correspond to the policy - the client could navigate to the account resource via the phone URL. I expect I could have constructed another policy to handle this, but I actually wanted to show an explicit entitlement call.