My manager keeps talking about how I will be "developing" an Application Express "security module", however from what she told me we need to have, I don't see what there would be to develop, seeing as Apex already has authorization/groups which allow for various groups of people to see various content.
Is there something that I am missing? What does she mean by a "module", or is it just general wording?
APEX provides several different ways to authenticate users. One approach is to use the "Application Express" authentication scheme and just to create APEX users. Another approach is to use the "Database Account" authentication scheme and to create Oracle users. A third option is to create a custom authentication scheme and to implement your own user management functionality.
Application Express authentication tends to be the easiest to deploy for a small application but tends to get unwieldy over time. It's hard, for example, to give an application administrator the ability to create APEX accounts. You can't tie an APEX account in to a single sign-on solution. It's not easy to integrate with the permission management systems that other applications use. If you're deploying an application in a large company, the last thing the security department needs is one more place where they need to create user accounts, manage privileges, de-activate accounts when someone leaves or changes roles, etc.
Database authentication tends to be more scalable than APEX authentication since Oracle database account provisioning is likely already part of your organization's authentication and authorization infrastructure. On the other hand, that still means that you're creating an Oracle database user for every user you want to create in your application which probably involves a call to a DBA (technically, you could create database users from your application, but most DBAs are going to be concerned about the security implications of that). If you intend to create an internet-facing application with tens of thousands of users, database accounts may get unwieldy.
I'd wager that the vast majority of medium to large-scale APEX applications use a custom authentication scheme. That may involve creating a USER table where you store the username & the hash of the password or a query against an LDAP/ AD repository. That sort of approach provides the most flexibility since you can code whatever you'd like into the authentication system. You can hook into whatever custom authentication/ single sign-on solution the organization happens to use. It probably makes creating new users from within the application much easier (obviously depending on how the authentication system is designed).
My assumption is that your manager is expecting that you'll be writing a custom authentication scheme for your APEX applications.
Related
we have a big distributed and multitenant system with all sorts of accounts :
- admin and backoffice users account
- customer account
- cashier account (tenant : there is one or many more cashier for each client tenant)
All this account are sharing more or less the same lifecycle (account created, grant on some ressources, deny account, password reminder...)
But they are not used in all applications of the system : some account would be used on specific or just two application for example.
Furthermore our system should have the possibility to have a bridge with a CMS for the customer management, or the backoffice users account could be authorized one day against a ldap...
So the question : we are searching for the best way to model our right and authorization service(s).
One idea is to create one service in order to manage all types of accounts of any kind : that is a SOA way to modularize our system
And one idea is to create different services : perhaps much more a micro-service oriented way of thinking...
What are your opinion ? I am searching some advices and feedback on this two different approach or perhaps an alternative that we habve not thought about...
If you are looking for any open-source solution for your problem, you can have a look into keyclaok.
Keycloak also got place in Thoughtworks Technology RADAR.
It is very promising solution and has LDAP, Multi Tenancy support also. checkout keycloak features.
There is paid solution like ForgeRock is also avaible.
Coming to feedback which you have asked about SOA or microservice way of implementation here (You will get different feedback/advice on this)
It will be better if you have a service to take care of access and authorization management and other to look into user details. If you meant that having different services for different account then note that Having one service for taking care account is still considered as Microservice approach as there is one dedicated service to perform single set of tasks.
You can have User-Service for user information management and a authService to handle access and authorization of users. check.
I want to build an web application in Oracle APEX, where i want users to enter into the database server through the application server, thus i can ensure more security in my application. IF this is hard, then is there any other way where i can ensure more security in a web application in Oracle APEX?
Oracle APEX is a very stable and secure environement.
As is,
you can encrypt and enforce high level passwords for the users
you can lock account to avoid brute force attacks
Devs and admins have accounts locked after a few attempts by default to avoid this issue
The service can be easily configured with any SSL
Webservices, like most of them, can be programmed to use access_tokens and other validations.
To my knowledge any additions security could be configured on the server and firewall. So I would say that you can do I lot, but it is up to you to perform good practices when defining your system's security.
Hope ity helps and good luck! :)
In the Oracle documentation, it is repeatedly mentioned that it is preferable for all users of an application to be database users instead of just records in some kind of 'user' table for numerous reasons. For example, at docs.oracle.com/cd/B28359_01/network.111/b28531/… -- "Where possible, you should build applications in which application users are database users. In this way, you can leverage the intrinsic security mechanisms of the database."
I am reasonably familiar with what they call the One Big Application User pattern, but I have been suitably convinced that this is not the best way. However, it seems that creating a database user for every web user is not particularly possible either, so my question is, what are some best practices for keeping the security definition of your data separate from the application that accesses it?
Some ideas:
A secure interface in between the database and the application. Application never knows about the database.
Create views that utilize application context to automatically filter out rows that the application user cannot read, and only grant the application user access to the view.
Similarly create procedures that utilize application context to only allow authorized data access/manipulation.
I am currently using Oracle 11g XE, and I'd like to avoid solutions that involve additional Oracle products like their Internet Directory or Middleware.
I am looking to learn a little more about Oracle Identity Analytics (OIA) and how it works in conjunction with other Oracle Identity Management (OIM) products. For example, what is it's role in Identity/Access Management and how do companies typically utilize it?
You can think of OIA as of an accounts and entitlements warehouse where you'd go to figure out who has access to what, when OIM is more oriented to providing automation in managing (granting and revoking access).
Where I work we utilize it mainly for Identity Audit. It covers prevention and reaction to Segregation of Duties violations. ( For example developers shouldn't have direct, high-privileged access to production environment - that would be a violation ). It's done by designing and executing Identity Audit Policies and Rules against set of employees.
Unfortunately the tool has a lot of deficiencies, so one needs to test it thoroughly before making final decision. Some of them you will be able to solve by writing some small scripts, but some of them are fully on Oracle (scaling, performance, WebUI) so you might want to wait to find out more details about OIG (Oracle Identity Governance suite) that they've announced in Oct'12 ( http://www.oracle.com/us/corporate/press/1859216 )
Oracle Identity Analytics (OIA) augments the provisioning, re-certification and privileged access components of OIM by allowing you to run Audit Policies and Role Management.
OIM allows you to define roles to automate and simplify provisioning, but it does not have the role mining capability to suggest roles based on Who has access What already. Therefore in OIM you have to manually define the roles for users. OIA can partially automate the process by looking at the data bottom up to find commonality. Oracle suggest a hybrid approach, a combination of the two.
The audit polices are aimed at Separation of Duties (or toxic combinations) which allow you to prevent access being granted where there is a conflict of interest. A typical example would be the permissions to raise a payment request and permissions to approve a payment request in some software. This is particularly important in highly regulated environments such as banking and the health sector.
In OIM for Privileged Access you would not normally use a SoD constraint for a user to have both a non-privileged and a privileged account. In fact you would want a user to by default use the Standard account and then Step-Up through a break glass process to get their password and use a Privileged Access manager to maintain the audit trail. I am more familiar with CyberArk than the Oracle product included as part of OIM.
Under Oracle Identity Governance 11g PS 2 the licence agreement should give you all the products in the suite. Over time Oracle are further integrating the two products.
My team will develop an internal (known users) application that has an architecture based on Java as front-end and PL/SQL as back-end. So, currently we are thinking in a better solution to manage the user/permissions, and we have two options:
Each user has their own database account, granted with the permissions. Currently the legacy system use this approach and I don't like it because it manages permissions based on database objects' granularity. So, I believe it is a bad choice to have a database connection per user. Can you see more cons here?
Build some tables at database to store the users and theirs permissions/profiles and build a PL/SQL procedure to do the login, generating a token and include a parameter to all others PL/SQL to verify this token and then authorize (or not) the execution.
So, you can ask me: why not just manage your permissions in your web-application? Answer: Those PL/SQL are already done and are used by all legacy systems, and this web-application should behave according it (ie. User permissions should be managed by the PL/SQL and its granularity based in please.)
How do you proceed in this case?
I think using the database's built-in mechanism is always to be preferred over rolling our own. And that applies to logging in users as much as anything else.
The biggest single advantage of dedicated user accounts is that we can link a given session with a named user. Well, yes, duh. But the point is, doing thinks like auditing user activity or tracing a performance issue in some process is way more difficult in web applications with generic accounts.
To address your main objection, we don't have to manage database privileges at the user level. That's why we have roles. For normal users, a role will provide sufficient privileges.
So:
define a set of roles which match the various business jobs your application serves.
grant system and object permissions to those roles; remember that roles can be additive (i.e. we can grant privileges on a role to another role).
grant roles to the users.
Find out more.