I've seen various posts that help you reset the password when it expires (using various means ACC, DB update etc). But, is there a way you can make the admin password never expire? We have lot of automation built around this admin interface and it is turning out to be a hassle every time this password had to be changed. It would be nice if we can make the password never expire.
Set the enabled property on /atg/dynamo/security/passwordchecker/ExpiredPasswordAdminService/ to false.
Below is a sample ExpiredPasswordAdminService.properties file. You will need to create this in the appropriate configuration layer:
$class=atg.security.ExpiredPasswordAdminService
# Enable/Disable the password expiration service
enabled=false
Related
I want to secure my user registration page with keycloak but couldn't think of any approaches while reading the docs. The best option for me:
New user register, but his account is unavailable.
When ADMIN accept this new account, user can log in.
Is it possible do it in keycloak ? Or any similar solution ?
Sure you can do it. The easiest way is to give a default role to newly registred users. The default role would give only minimal privileges. Then ADMIN can promote the user to the more appropriate group or role.
Probably to "automate" or smoothen the second part of this flow you might need some flow customization. Cf. https://www.keycloak.org/docs/latest/server_development/#required-action-walkthrough and related.
Another solution is to give to the default minimal role the possibility to request acceptation, or make the request automatically at first logging (eg. mail sent to ADMIN).
EDIT
Programmatically it is also possible to make calls to the Keycloak Admin API (through native Admin Client). For example, you can write some logic (and associated UI or whatever) that will assign or remove groups from a user.
See. Admin REST API
Is it save to create backend user with an empty password?
For example the _cli_lowlevel backend user or a backend user editor-test, which I only use for testing purposes via the "Switch to user" feature.
usually a cli_* user should have no rights to access anything in the BE (non admin user, with no mount-points). it is used to execute TYPO3 by command line. if anyone can get access to a shell he can execute commands more dangerous than a simple BE-access. e.g. he can open access to the install-tool and create an admin-user. or use mysql-cli to set passwords to any given user.
normally you can not create BE-users without password as the form for BE-users requires a not empty password field. as you probably use salted and hashed passwords even a simple password can not be decrypted (so a brute force attack may find the password quickly). so the best way would be a long random password which you might forget the next moment.
i have deployed my cas.war file.
Default login is working fine.
For enabling Remember me, i followed.
https://wiki.jasig.org/display/CASUM/Remember+Me
but still when i do login selecting remember me option.
It simply logs me in without remembering.
So each time i have to enter username :test & password: test while accessing:
localhost:8080/cas/login
i want it to once allowed login to remember, so that for next hit on
localhost:8080/cas/login identify me from cookies generated in remember me option
Any help from techno legends on this will be appreciated.
Where you are selecting remember me option, whenever you enter any username and password almost all browsers will ask Remember me option, if you are using the browser level option check the browser cache and auto-fill passwords are enabled or not (example- in Google chrome use ctrl+h),
If you are using CAS application level Remember-me, that behavior is different, when you use first time, in CAS data base your username and password along with you IP address will store, next time when you enter your username immediately from database your password will come.
I'm looking at developing an application using the Yodlee FinApp API.
Their REST protocol requires you to login your users to their system to retrieve data. To do that, you need to send a login and password. A successful request returns you a token that is valid for 30 minutes. Before that 30 minutes elapses, you must log the user in again in order to retrieve a new token. Here's where the problem lies, in my opinion.
I could set something up wherein every time a user logs into my application, I immediately send their login info and password to Yodlee and log them in there as well. Then, I wouldn't need to store their password in my database in plain text. But what happens when 30 minutes elapses? I don't actually "know" their password, so I'm unable to get them a new token and would require them to log in again. It would be a real pain to have users constantly having to log back in every 30 minutes.
Alternatively, I could generate my own password for them when they sign up with my app and use that for my application's interaction with Yodlee. But then I have their Yodlee password stored in my database in plain text. Assuming somebody was able to gain access to my server, they'd have my application's credentials and also all user credentials, so they'd be able to mimic my application's process for logging in and gain access to user transactions. This seems like a bad idea.
What's the correct approach here? It seems like both of the avenues I'm investigating have serious downsides, but maybe I'm missing another option?
#aardvarkk- How are you planning to authenticate the user on your application?
If I understand correctly then you should be storing the user credentials in your application to validate the user and also to check if he/she is a new user or not.
When you would be having this data, you can use the same to login again on behalf of user before 30th minute & only when user will still be in session not every 30 mins.
And we would suggest you to not to store any of the user's credentials in plain texts. You could encrypt it before storing and decrypt before sending it to Yodlee.
Also, the access to your application credentials for Yodlee's production environment is IP restricted and hence only request's coming from your static IP can connect successfully to Yodlee.
[UPDATED]
For this Case:
You can call touchConversationCredentials API which extends the relative (or inactivity) timeout validity of the conversationcredentials i.e. UserSessionToken. You need to pass userSessionToken in this. And you can call this before 29th min of user session to extend his/her session for another 30 mins. But there's an absolute timeout of 120 mins, so after 120 mins of initial session creation it will expire.
First off, really try to avoid storing the user's password in plain text. That is just asking for a world of pain if anything goes wrong (e.g., if you get hacked) and can open you up to all sorts of legal trouble. Truly, don't go that way.
It would in fact be better off if you never learn their Yodlee credentials at all; you don't want to be them, you just want to interact with the system on their behalf.
REST doesn't really say that much about how systems authenticate to one another; many possibilities are available in general. All you can do is try to connect with whatever credentials you have, and if that fails, bail to the user (well, to client-side code) so that they can give you another token. REST does clearly state how a failure to authenticate should be conveyed, a 401 HTTP response, but that's all really.
I have a simple webpage deployed to tomcat which runs certain shell scripts based on user selection. The pages are written in html and cgi/perl.
We already have a working ldap server and directory. I need to be able to add security to the web page I created so a user is asked to login using their ldap account when trying to access the home page or any off the sub pages.
How do I add ldap authentication to my web page?
Please be very specific as I am new to all of this. Step by step instructions including code would be greatly appreciated. Thank You
I did a lot of research on google, but all of the solutions are generic, and I don't know where to start.
This is a good article, but I'm not sure where do I put my connection to ldap and the binding (which of my pages)? How do I make sure the authentication will apply to the sub pages as well, or any other one created in the future?
http://www.perlmonks.org/?node_id=32196
Cheers
This is a good article, but I'm not sure where do I put my connection
to ldap and the binding (which of my pages)? How do I make sure the
authentication will apply to the sub pages as well, or any other one
created in the future?
You're now adding state to your app. You might initially think about implementing your authentication (authn) and authorization (authz) in tomcat, and not in your app.
If you decide not to implement in tomcat, and choose to implement in perl, then you've just decided to add state to your application, which means you need to add some kind of session handling. Look at CGI::Session, there are many other session handling modules on CPAN. Avoid Apache::Session. Its lock handling can cause lots of pain if transactions run long. Use a session key in a cookie. Send everything over SSL. if you don't use SSL, then crackers can intercept your session keys, and then hijack the sessions.
Once you have your session infrastructure set up, you need to create a login mechanism, usually a form with username and password. when that form is submitted, the CGI behind it does its magic crypto on the password and then does the LDAP dance:
connect to the directory server is no connection already exists.
2a. bind to the server anonymously or as an application user, search for the user by CN, bind as the user using DN and password
OR
2b. compute the DN form the username, bind with the DN and the crypto's password.
Often, step 3 is to check the user's record for some authorization indicator, it could be a yes/no access indicator, or it could be a list of roles or privileges.
If the user is successfully authenticated, and authorized, then write some authorization info into the user's session.
Each subsequent page of your app will then check to see if the user is logged in and/or has the proper authz to use that page. If unauthorized, you can either send them back to the post-login landing page, or to the login page if they aren't logged in.
Basically, you just replacing the usual "query the user table of the database" with a query to an LDAP to a directory server.