I'm using LifeRay and need some kind of special authentication: my users have x.509 certificates which are validated by an Apache Webserver. After a successful validation, the user is redirected to Tomcat and in there LifeRay.
Now I want to do the following: get the subject DN of the user's certificate programmatically and log in the LifeRay user that is connected to this DN.
So far, I have the following:
Created a hook "login.events.pre" where I get the DN from the certificate
Search the LifeRay DB for a user with this DN (using UserLocalServiceUtil.getUserByOpenId())
Authenticate user using UserLocalServiceUtil.authenticateByScreenName()
My question now: is that the "best"/cleanest way to do this or should I use other methods for querying the LifeRay DB, authenticating the user etc. For instance, instead of a hook I could create an Ext-Extensions for LifeRay. Additionally, I found some stuff like "com.liferay.portlet.login.util.LoginUtil.login" or User user = PortalUtil.getUser(request); to get a user.
Is there a place in the docu where those questions are answered? The API is not that comprehensive...
Related
I have successfully added ldap-ad to Alfresco. Now when i am creating a user in AD, it is synchronized with Alfresco and i got an Alfresco user. The question is, if a user Bob (that has been sync from AD) changes his password (in Alfresco interface), in which authentication system the password will be changed, Alfresco or AD?
If the password will be changed in AD, then i have no other querstion, but as far as i know, there is only one direction sync, from AD to Alfresco, so Alfresco cant access the AD passwords and change them. Does this mean, that Alfresco will create a password for Bob and store it in its own authentication system and now Bob can loggin with alfresco and AD passwords (new and old)? And most important question: How to avoid that? Thanks in advance.
Alfresco uses an authentication chain concept. That means you can configure more than 1 system for the authentication and if a user tries to authenticate Alfresco steps thru the configured chain and tries one system after the other until the user has been authenticated successfully or if the auth fails on the last chain member the auth attempt is assumed as failed.
Alfresco brings it's own authentication subsystem to create and store users locally in the repo db with passwords. Locally created users like admin are stored in the local subsystem alfrescoNtlm which you could find in the node browser in the user://alfrescoUserStore/ store. That store is for the authentication of internal users only.
"users" you see and manage in the Alfresco UI are of type cm:person stored in the main store workspace://SpacesStore (/sys:system/sys:people/) but do not contain any password at all.
The ldap sync only creates users in the workspace://SpacesStore under /sys:system/sys:people/and once a user tries to login Alfresco walks thru the authentication.chain which may look like in production:
kerberos1:kerberos,ldap-ad2:ldap-ad,alfrescoNtlm1:alfrescoNtlm.
Alfresco Share only provides the user a "Change Password" dialog if the user is found in the local alfrescoUserStore. Alfresco does never change a password in any other system.
To test whether you have understood everything: What happens if a user max exists in the AD and in the local alfrescoUserStore and changes it's password in the Alfresco UI? ;-)
If you were using LDAP for authentication, then the passwords will never store in Alfresco. Passwords will be stored in LDAP and and it will be linked with Alfresco by their email or usernames.
User is authenticated on website using LDAP. How do I automatically authenticate the same user on another website using LDAP. The two websites are on the same domain but separate websites- they both authenticate against same LDAP store. Is an authentication token somehow passed from one to next? Or the credentials or something..? Sort of new to LDAP auth...
You can not use LDAP to achieve Single Sign On. LDAP is an 'authentication protocol' and a 'data model'.
You either need a proprietary mechanism or some standards based technology like OIDC or SAML.
I want to implement FORGOT password and I need to set the new password for the user without knowing the original one. Because of that I cannot authenticate to LDAP (ApacheDS) with the user credentials. However, when I change the password using the admin credentials the password policy is not applied.
So, I'm trying to see if I can authenticate as the admin but act as the user. Is there any way to implement this functionality against ApacheDS.
Consider using the Proxied Authorization Control as defined in RFC 4370. I am not an Apache DS expert, but I could find the following control on their site.
The ldap.com site also has an example on how to use this control (Scroll down to the section called The Proxied Authorization Request Controls. The code snippet is using the UnboundID LDAP SDK for Java)
I hope this helps.
EDIT: I've created and published a meteor package that integrates the ldapjs node package see accounts-ldap
Feel free to submit any issues or pull requests on the github page
Original question:
Users are authenticated through ldap and I've created a custom login handler that works properly against ldap (Accounts.registerLoginHandler(...)).
Currently, I need to import user accounts on startup. Because I'm using ldap as a 3rd party to authenticate, I won't be able to store passwords for the users. I'm wondering how I can hook in to validate user logins without storing the password.
So the real question is:
How can I authenticate users on login without having a password?
You can autenticate to ldap get user id/name check exist in meteor users than can impersonate that user using:
(In a server method)
this.setUserId(userId);
Where userId is imported meteor userid.
I am wondering how CAS works (workflow needed). Imagine:
User authenticate with CAS on App1 (example.com/app1, for example).
User goes to another application (example.com/app2).
Every application must show user's name on top of the page. How they know it? In case of just ONE application, the workflow is pretty clear:
App1: While user browse pages without authentication, just show "Login" link as user name.
App1: At one moment user presses Login.
App1: Redirects user to CAS
CAS: Requests user's login/pass
CAS: User enters login/pass
CAS: Redirects user back to App1
App1: gets token and user name (or ID) from CAS, and gives some rights to this user.
Done.
But now: how the App2 (App3 and so on) knows that user is already authenticated? Do they all have to redirect user from EVERY page to CAS just only to know, if the user already authenticated and request his name?
In case of Spring it will be a huge redirections, while I have some independent applications like:
example.com/App1
example.com/App2
...
example.com/AppN
I don't have have 10 reputation yet, so you will need to check the workflow image at
http://idms.rutgers.edu/cas/how_does_it_work.shtml
When a new user initially logs into an application they won't have established a session with the application. Instead of displaying a login form asking for the username and password, the application (via the CAS Client) will redirect the browser to the CAS login page.
CAS then authenticates the user. If the authentication fails, the CAS login page is displayed again with an error message. So until authentication succeeds, the user will not be returned to the application. If the user is not sure how to proceed at that point, there are help desk links on the CAS login page. Once the user authenticates successfully, CAS will redirect the browser back to your application. CAS knows where to redirect to via a {service} parameter that you append to the CAS login url.
When CAS redirects the authenticated user back to your application, it will append a {ticket} parameter to your url.
The ticket returned to your application is opaque, meaning that it includes no useful information to anyone other than the CAS Server. The only thing that your application can do is send this ticket back to CAS for validation.
CAS will then either respond that this ticket does not represent a valid user for this service, or will acknowledge that this ticket proves authentication. In the later case, CAS will also supply the username so that you know the identity of the user.
The application must provide its own session management. Once the user is authenticated, your application should keep track of this fact within a session so that you don't have to reauthenticate them with the CAS Server. Typically this would be the same as if you authenticated the user directly from your application.
Each application should provide their own logout facility which will invalidate the session and require the user to re-authenticate into the application. Note that if they are using SSO through the myRutgers portal, they will not have to re-enter their username and password.
Using CAS means, that the CAS-Server keeps track of which user is authenticated globally (using a cookie which stores a Ticket Granting Ticket Id - TGT). Each application must maintain its own mechanism to key track of a principal session and the corresponding information.
So if a user wants to access a secured application APP1 (and is not authenticated), he will be redirected to the CAS-Server. Without sending a valid TGT the login-form is presented, otherwise (or after successfully authenticating to the CAS-Server) a Service Ticket (ST) is generated, which must be presented to APP1. Here this Service Ticket is validated against the CAS-Server (using server-to-server communication) - if valid, the userId (and perhaps additional information) is returned.
Now it's up to the application APP1 to create a principal based on the userId and to provide authorization information (e.g. the CAS-Server authenticates against an LDAP, whereas APP1 stores the user data in a database).
All subsequent requests to APP1 should not involve the CAS-Server anymore.
If the user makes a request to APP2, the mentioned process restarts again.
L'sync,
Have you tried posting your question to the cas-users [cas-user#lists.jasig.org] mailing list?
I have been working with CAS for the last 6 months and from what I understand, App2 (App3 and so on), without redirection to CAS do not have a way of knowing the user-attributes.
You can avoid putting all pages of App2 behind the CAS filter by either storing the user-attributes along with your web-session and/or by embedding an iframe-header in your pages which displays the login-name.
Marvin who is a CAS contributor maintains an excellent CAS client test webapp on GitHub where you can see how he reads the user-attributes.
https://github.com/serac/java-cas-client-test