I have a application that use Jpa Hibernate,Spring Data, Spring security, but I want more control over password rules and users, for example, password expiration time, session time, inactive session time, etc.
Spring security can do all these tasks automated?
Other possibility is to use LDAP, to control password policy, but I already have users defined in my application and I can't see how LDAP server can read my users to apply the polices, or the users have to be in the LDAP server to authenticate in my application?
I installed apacheds server to test.
I need to know if I'm using the right approach to solve this problem.
If you use the LDAP password policy it will apply to existing users next time they change their passwords, and you can force them to do that.
Session inactive/expiry time has nothing to do with password policies as implemented in LDAP.
Related
We are in the planning phase of configuring our soon-to-be-upgraded databases (19c) to authenticate directly against AD (no oracle proxy). I have read a handful of documents from Oracle on how to do this. Most of the documentation focuses around using passwords (password filter/verifier). The only problem is that our AD administrators are dead-set against implementing Oracle's password filter into our existing AD infrastructure. That being said, one of the security guys said we could implement the oracle authentication using Kerberos instead. From what I have read, and the documents are scattered all over the place, and nothing that detailed, to use Kerberos:
1) The client no longer uses a username/password - they connect using a wallet-style connection (e.g. /#dbname)
2) Not only does the Oracle DB need some configuration changes, but so does every client that plans on using Kerberos
I don't know anything about Kerberos, how it works, and what goes on when you implement this, but I was hoping for, at the end of this is:
1) No client changes/installs (only the oracle DB would have config changes)
The user will continue to provide credentials as before - completely transparent
2) No need for the password filter as our admins have a "beef" against it
So my question is:
If using Kerberos directly against AD on >=18c:
1) Does the client user still provide a username and password to authenticate against AD, or does the client simply get "accepted" due to the tickets/tokens/configuration that occurs on the client (i.e. the client is simply trusted)?
2) Is there client config changes that need to occur, or does the client reach out to the DB and the DB, with its config changes, does all the legwork to authenticate against AD based off of client info being passed
3) Does any additional manual component need to occur on occasion (periodically retrieving a ticket/token/something) (because, say, it expires)
So in the end, we want to have complete transparency with every client and using something other than the password verifier with AD.
Thanks in advance.
-Jim
It sounds like you want to authenticate Windows clients against an Oracle database over a network using Active Directory without making any client changes.
This is pretty open-ended and complex StackOverflow question.
Probably you've been reading the docs about Third Party Network Authentication using Oracle Advanced Security. You can use Kerberos, SSL, RADIUS, PKI, etc. For most of these options, you need to do some setup on the client, because both the Oracle client and server need to authenticate or verify with the third-party system.
I think you need Enterprise User Security (using Oracle Internet Directory). Assuming you go with password-based authentication, you don't need client changes. In this scenario, Oracle Internet Directory can synchronize its user directory with AD, so your users can use their same username/password. However, when they change their AD password, they'll need to change their Oracle password separately.
On a different note, you may be able to alleviate your AD admins' fears about Oracle password complexity requirements, since you can change or remove those to fit your AD requirements.
Currently my Mac has been successfully configured to be in Active Directory Domain. (System Preferences -> Users & Groups -> Login Options -> Network Account Server)
We are developing a Mac application that has following requirements:
It should communicate with the LDAP server in Active Directory Domain and retrieve users & their attributes from LDAP server.
While communicating (bind or search) with the LDAP server, we are not allowed to explicitly specify logged-in user's credentials. (e.g. we should not prompt username / password screen to the user)
If we explicitly specify logged-in user's credentials,
• we are able to bind to the LDAP server
• we are able to search the users & their attributes in LDAP server.
If we do not specify logged-in user's credentials,
• we are able to bind to the LDAP server
• but it does not allow us to search the users & their attributes in LDAP server.
We are currently using OpenLDAP framework for LDAP operations.
Is there a way with which we can use logged-in user's credentials implicitly while communicating with the LDAP server?
Can you please guide us how we can query LDAP server (search users & their attributes in LDAP server) without specifying logged-in user's credentials explicitly.
Any kind of help is highly appreciated.
Is there a way with which we can use logged-in user's credentials
implicitly while communicating with the LDAP server?
Maybe.
IF you CAN set up Kerberos (and SPNEGO is using a WEB browser) you might be able to obtain a "ticket" that you could then use a GSSAPI to Authenticate the user.
You would probably be more secure if you used a one of the many third-party Access Manager Products to perform these services due to the inherent security risks involved.
I know simply a LDAP bind can do user password verification. But the thing is that an application server usually uses admin user (cn=Directory Manager) to do all CRUD operations.
By a simple bind operation, we have to create a ldap connection binds with that specific user's dn , which is annoying.
As I know ldapcompare is another alternative, but looks like OpenDJ ldapcompare can not compare plain-text-password(OpenDJ userPassword is encrypted).
But from some ldap browser(Apache LDAP Studio), there's a "Vefiry Password" which works very well.
Any idea ?
Using cn=DirectoryManager from an application server is a security issue, pretty much like running applications as root in the unix world.
Have you tried using the proxyAuth control?
Here are a few relevant links:
https://marginnotes2.wordpress.com/2011/06/28/opendj-proxy-auth/
https://idmdude.com/2015/03/28/opendj-and-the-fine-art-of-impersonation/
i am developing a server application of building rest web services in java using spring-hibernate,where this service will be used by other clients.i have followed this link http://www.beingjavaguys.com/2014/08/spring-restful-web-services.html.
my question here is
1>should i maintain session in server application?if yes how?
2>should i do any validation in server side?
3>To validate user while login should i use spring security for that or just comparing username and password in database is enough?
4>when user doesnot interact with server for particular time there should be session timeout ,should this be implemented in sserver application or client side?
i am very new to java and web service,any suggestions,links and guidence are appreciated.
1>should i maintain session in server application?if yes how?
Rest web services do not depend on client session since they are stateless, so there is no need to think about session management.
2>should i do any validation in server side?
What kind of validation?
3>To validate user while login should i use spring security for that or just comparing username and password in database is enough?
You can use both, but I think a token based authentication (Based on spring security) will be the best way.
4>when user does not interact with server for particular time there should be session timeout ,should this be implemented in server application or client side?
Since server does not keep track of user session, timeout should be implemented on client side.
You can check the following project if you want its a excellent starting point.
https://github.com/dhavaln/spring-rest-boilerplate
1>should i maintain session in server application?if yes how?
Web-services are stateless means server does not store any state about the client session on the server side.You should manage the session on the client side, other wise you will end-up handling an heavy load of sessions on the server side and I am sure you don't want to do that.
2>should i do any validation in server side?
If by validation you mean data integrity, I think you will have to do it for the favor of data integrity and your application well being.
3>To validate user while login should i use spring security for that
or just comparing username and password in database is enough?
You can do both, using spring security is a good choice , and you will have to configure or build your own AuthentificationManager which will compare credentials withe those stored in the database
4>when user doesnot interact with server for particular time there
should be session timeout ,should this be implemented in sserver
application or client side?
You can set a session timeout , and this should be implemented on the client-side.
I need to be able to store a user's Exchange password so I can use it to perform some task later on, using EWS. I know storing passwords in plain text is a horrid crime, so what options do I have?
In my case, my application will have access to an administrative account that will have the ability to use impersonation to work with users' Calendars. I need to store the password of this admin account so I can use it while authenticating with the Exchange server at a later time. I am not planning on using the EWS Managed API.
I have a user that created a calendar app with similar requirements. By default, an account that has these permissions globally is horrible and not recommended. Impersonation roles were granted by department that required access to the app to reduce risk scope. However if you require this globally, here's what I recommended for mitigating the account/password exposure:
Restrict the accounts functionality to Exchange services only. Features like log on locally and other general domain user privileges are not needed for an EWS service account that only needs mailbox access and impersonation roles. In this case, the account cannot log onto a computer nor can it be used for RDP. This limits exposure for malicious use.
The user/pass can be stored in your applications database and the connection string would also be stored outside of your application, there's a lot here: https://security.stackexchange.com/questions/22817/how-to-encrypt-database-connection-credentials-on-a-web-server and encrypting the password within the database; further reading: http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374
Restrict DB server and management access. This is a larger issue than it should be if the database server is shared between groups. Audit the database server access, and re-restrict if you have too many cooks in the kitchen. The database server should also not be directly accessed by user networks but that may be a larger issue to tackle.
Restrict access to the application. As in, is it available externally or only available inside your perimeter? Either way, the application should also include authentication just to access, using Kerberos or some other SSL auth, make sure the application cannot be used to DoS the EWS services from over-access.
Create a one-off throttling policy on Exchange for this user and assign accordingly to prevent the application from breaking EWS or limiting regular user functionalities. This is something Blackberry admins learned the hard way if they didn't follow recommendations. When BES server wouldn't properly tear down connections, web services would start dropping valid client requests. As such BES had to instruct users to create a one off throttling policy for various Exchange features. I did the same for the user that created my EWS app. And a few times it saved me.
Really it will boil down to good application design and coordinating requirements with the Exchange team.
Don't's:
Don't store the username/password in Apache/IIS pages or the connection string
Don't grant global permissions for the account if you don't have to
Don't allow unauthenticated access to the application and allow unlimited connection times
Hope this helps.