Users and Architecture

Question

On my local instance, I would like to create a user account for each of the 600+ employees at my company.
I want a mechanism for the HR department to maintain these users and delete/inactivate them when they leave and add new users themselves.
I may also, in the future want to add non-employee users.
What GUI mechanism is there for HR to manage the users
If I need to build, should I use the WWV users table in Marvel. What permisions on a flow do non-developer users get?
is the employee_id column there for me to use?
Also the attribute columns (the last columns in the wwv user table), are those for me to use? Or reserved for future use for the Marvel group?
Where is there more information on this topic...give me suggestions and get me started and If needed I will program what I need.
Thanks,
Meyer

Answer 1

as you might imagine, the means by which you store your users and manage their access are very related. marvel's incredibly flexible with respect to security (authorization and authentication), so it's your choice as the flow developer as to how you want to implement them. we have some pretty good info on this subject in the online help in marvel, too. you can get to it after logging into marvel.oracle.com at http://marvel.oracle.com/pls/otn/f?p=4200:4402 by clicking on the links for "Authentication" and "Authorization".
most of your questions above seem to focus on our built-in tables used for authentication (and some authorization). as with everything, there are pros and cons to using these tables/views (wwv_flow_users and wwv_flow_user_groups). i think it's safe to sum up the pros of using our tables by saying that you can leverage the built-in functionality that we provided you. conversely, there's chance that we haven't thought of everything you might need for your particular scenario, so you might be limited in what you can do when you use our tables. i suppose this might be kind of obvious, but i think it still needed stating. after reading over our auth docs online, you'll understand more about what we do and do not offer, but the gist of what makes using our stuff appealing is that we've written the api's for you. using the api's, you can do the stuff that most security schemes need to do (things like check username/password combos, verify a valid sessions, and change passwords). with this functionality under the covers, you'd simply build the screens to expose it. speaking of exposure, i just took a super quick look at this online security documentation that i've referred to, and noticed that the doc for the wwv_flow_user_api which, of course, helps to manage and check against the wwv_flow_user view is in its own home at http://marvel.oracle.com/pls/otn/f?p=4200:59. also, the api that you'd use to insert and remove users from the wwv_flow_fnd_user table (the table upon which the wwv_flow_user view is based) is called wwv_flow_fnd_user_api. it's not very well documented online, but the package spec pretty much tells you what you need to know via comments. please take a look at all this and let us know if you have further questions. if you have questions specific to your scenario, feel free to shoot an email with the details to [email protected].
hope this helps,
raj
The Project Marvel Team
ps-for what it's worth, it's my personal preference to create and manage my own auth tables in my marvel apps. simply put, i'm comfortable doing it, and i like the level of control.