I have a list of users who are past their expiration date in OIM 11g r2 PS2. I am looking for a way to bulk disable these users in oim, thus trigerring the disabling of their AD and Exchange accounts. There are many and i don't want to disable them one after the other. I need a way to either
Invoke a task that will find every expired user using their expected end date and other criteria i specify and then disable them
OR
Invoke a task that will call a csv file with the usr_key or usr_login and then disable the accounts. I can create a powershell ecript to take care of the AD part but i really want a process to do this in oim without having to write an sql query to do it from the back end.
Thanks
There's a scheduler in OIM "Disable/Delete User After End Date",this should take care of your scenario of disabling users whose end-date had passed.
This scheduled task disables user accounts for which the end date had passed the current date at the time when the task is run.
And once the user is disabled in OIM,than automatically the AD/Exchange gets disabled.
As far as I know, there is no OOTB task to take care of that. You can write a short app to read your list of users, connect to OIM using OIM Client library, and use UserManager API do BulkDisable those users.
Here is a short snippet
final UserManager um = oimclient.getService(UserManager.class);
final ArrayList<String> lstUsers =
new ArrayList<>(Arrays.asList("LOGIN1", "LOGIN2", "LOGIN3"));
um.disable(lstUsers, true); //true means the list contains logins, not user keys
Related
I have a simple crud task manager backend. How can i separate the data between the users? For example if one user in one device adds a new task the second user can see, delete and update that task. How can i separate the users without making a login? I searched for a bit about sessions but i don't think that's what i want in this case.
I guess you can create a uuid whenever someone comes to the page, and save that uuid in user local storage in order to manage the records.
My title is probably vague so please check my situation below.
I have a web application to manage a list of employees. The application is set up in a hub-spoke pattern where clicking an employee from the employee list redirects to a new window showing the chosen employee's personal details for possible updates.
The application uses HTTPS. The employee list and details are retrieved via GET while the details are updated via POST. The application uses HTTPS and all users (there are only a few of us) have the authority to retrieve and update employee details.
My question is, will it still be required or suggested to check the employee ID (the primary key) during update/post operations? A sophisticated user can theoretically change the employee ID before the POST and update another employee's details even without pulling out the 2nd employee's record. Still, even if that user somehow fools the interface, any of his "hacks" would simply be acceptable since the user can retrieve and update any employee anyway.
So in my case, would you still consider it necessary to enforce a mechanism so that only the currently shown record is updateable? If yes, what are the accepted practices for implementing this? Thanks
Many web based systems are designed to be stateless. The main reason is to allow multiple sessions/windows.
You could potentially store the currently edited employee ID in a session variable and only allow changes to that employee ID, however, what if the user has two browser windows open in the same session? Now, you have to keep the currently edited employee ID for each window. Well, you don't have this information, so you have to store the employee ID in the form itself, and this is all editable by the client.
So, instead, simply enforce the rules on the server, and if they have permission to edit that employee, let them.
Ensure that your system is using HTTPS to prevent man in the middle attacks, escaping all output to prevent cross site scripting (XSS), and requiring POST for all updates as well as using sessions and form tokens to prevent cross site request forgery (CSRF). Once you've done that, any employee ID manipulation will likely be self-inflicted, and your job isn't to protect the user from themselves.
What you usualy do is - click on a row, get the employee ID and send it to the server, retrieve information by ID and publish it to the user. Usualy you keep the ID as some jind of hidden value, so when you update, you update this ID. And, usualy, you don't allow ID changes. IMO no need of checking ID, but if you think some one can jump over, just check if the ID of the page is the same you have in the hidden value.
I'm using my own User class as and entity provider for security system in symfony 2.0.
I noticed that on each reload of the page symfony is fetching user from db:
SELECT t0.id AS id1, t0.username AS username2, t0.salt AS salt3,
t0.password AS password4, t0.email AS email5, t0.is_active AS
is_active6, t0.credentials AS credentials7 FROM w9_users t0 WHERE
t0.id = ? Parameters: ['23'] Time: 4.43 ms
Is there any easy way to disable this behaviour? Maybe serialize user data in session variables or cache them some way?
You can change this behavior in the refreshUser method of your UserProvider.
You should be careful when doing this with doctrine: There is an issue at FosUserBundle github, explaining the pitfalls:
Storing it in the session would lead to several issues, which is why it is not done by default:
if an admin change the permissions of a user, the changes will have an effect only the next time you retrieve the user from the database. So caching the user must be done carefully to avoid security issues
if you simply reuse the user which was serialized in the session, it will not be managed by Doctrine anymore. This means that as soon as you want to modify the user or to use the user in a relation, you will have to merge it back into the UnitOfWork (which will return a different object than the one used by the firewall). Merging will trigger a DB query too. And requiring such logic will break some of the built-in controller which are expecting to be able to use the user object for updates.
I have a website that I'm working on, and its hosted on a shared hosting site that gives me 1 database connection.
Of course, that login has full access to read and write (as it is the connection I use to build my tables, etc).
However, I want to allow users to be able to write ad-hoc SQL queries, but I want to limit them severely... as an example, not being able to write to any tables.
So my question is - is there ANY way to limit ANY functionality at all at runtime... perhaps as a setting passed in the connection string?
Or is there something I can do in C#? (example: I can start a transaction and roll it back)?
Is there a reason you can't create new user accounts for each user? Then use the built in server security to limit what each user can do.
You could, for example, set up role groups for the new limited users, and then use table security to limit access.
grant select on my_table to limited_user_group
deny insert, update, delete on my_table to limited_user_group
You can use the EXECUTE AS t-sql statement to switch the execution context for the session to another user. You can use WITH COOKIE to lock the execution context down until you supply the cookie value with your REVERT statement.
So it appears that you cannot limit access to the very same user that you are... so what I'm doing as a workaround is I've created another database (a blank one) and I'm going to wrap all of the user queries in a transaction that I will force to rollback.
It's a yucky solution, but as Factor Mystic said in his comment - "get better hosting" is probably the best solution (meaning - the problem here lies with the hosting company).
CouchDB offers validation prior to allowing an object/row to be inserted into the database. This make sure that if you have a public facing couch application, you're database won't be filled with junk by just anyone.
User <-> CouchDB
However, I'm tring to figure out what that looks like comming from the standard application design process where you have a trusted middle layer that does much of the auth work. For example, most apps place Ruby or PHP between the database and user agent which allows the application to figure out information about the user agent before allowing something like a post to be saved to the database.
User -> Ruby -> MySQL
User <- Ruby <- MySQL
How do you trust the user to do administrative tasks when the user can't be trusted?
For example, how would you do something like "email verification" prior to inserting a user row using just couchDB? You can't let the user agent insert the row - because they would fill the system with spam accounts. On the other hand, there is no middle layer either that can insert the row after they click the link in the email.
How about this, I would assume that you would allow anyone to enter their email by creating a new record in a public table like email_verify. This is something that a public user agent could do as the table would not do anything in the application - it would just be a holding tank.
Then node.js could track the _changes feed and send an activation email while creating a new entry in a private table (like email_confirm) (node.js would serve as a trusted middle layer). If the user clicks that link and comes back then... [unknown] ... and node.js could finally create a record in the private user table (user).
At this point we could then rely on couchdb validation for the rest of the application since we got a confirmed user account created.
As more background lets imagine a discussion built on couchdb that anyone can register for. We don't want to allow just anyone to directly submit content without some kind of verification - yet the user agents all directly run the system. (Tables would be Thread, Comment, & User). How would this work?
I would think about adding roles to existing users in this issue.
Using couchdb's validation and changing _design/_auth can be a good idea to add email, email_verified and randomly generated email_verification_code in _users database when the user firsts registers.
To send mail, get confirmation, resend confirmation you can use external processes. (for an example usage of external process you can check couchdb-lucene).
And at last you can again do a quick check in _design/_auth in user update process if verification code matches and add verified_user role for that user.
This way all your requests would pass over couchdb, you would use external process only when you need to send mail and get confirmation.
Edit : Forgot to add (since it was pretty obvious), I would add verified_user role to database readers.
Couldn't you just make use of CouchDb's Validation ?
Users could be flagged. Upon registration, a User is added to the Users database. He gets his mail and then is flagged "valid:true" or something like this upon answering to that mail or clicking a link.
With validation users could not only be "logged in/out" but also access authorization can be implemented with more granular access rights. E.g.: Only mark threads solved if one is the author, admin, whatever...
Or does this seem impracticable?
After talking with some people on #couchdb IRC, it seems that they can't figure out out a way to do something administrative (like activation users that click on a email link) with out using a "backend" process like a node.js server which keeps track of the _changes feed.
I was hoping for a pure couchdb app - but it seems like couchdb still has a little ways to go.
Still, the good news is that you can hand off 80% of your applications logic/processing to your users. The other 20% will be 1) a node.js instance for things like sending emails or checking recaptcha and 2) record validation functions running in your couchdb, and 3) map/reduce (query) functions. These three things cannot be offloaded to something "untrusted" like a user-agent.