liferay add user from API

[G R, modificado 7 Anos atrás.]

HI,

I am using Liferay API to add new users based on some logic. The sample code is below.

UserLocalServiceUtil.addUser(
creatorUserId, companyId, autoPassword, password1, password1,
autoScreenName, screenName, emailAddress, facebookId, openId,
locale, firstName, middleName, lastName, prefixId, suffixId, male,
birthdayMonth, birthdayDay, birthdayYear, jobTitle, groupIds,
organizationIds, roleIds, userGroupIds, sendEmail, serviceContext)

the password is generated using : PwdGenerator.getPassword() and autoPassword false.

Is there any way we can enforce that the users which are created using Liferay API in my code cannot be logged in through Liferay UI(example from where omni user can login )

[David H Nebinger, modificado 7 Anos atrás.]

No. A user is a user and, as long as they are active, they will see the login form whenever they try to access a protected resource.

[G R, modificado 7 Anos atrás.]

HI,

thanks.
can a user be created without password(no auto generated password) from Liferay API ?

[Andrew Jardine, modificado 7 Anos atrás.]

I don't think so. As far as I know there are a few required fields for creating a user --

+ User Id
+ Email Address
+ Screen Name
+ Password

... and I feel like there is a 5th, but I can't recall right now. The UID, screenname and email are necessary because those are the three auth types that you can choose from so all need to be available (and unique) in order for those mechanism to work for all configuration types. Password, well, that should be obvious why you need it (regardless of whether you provide it or it is auto generated).

Question: What exactly are you trying to do? You want to create accounts in Liferay but not let anyone who is not an admin log in?

[G R, modificado 7 Anos atrás.]

HI Andrew,

I am creating liferay accounts from Liferay API in Autlogin, but do not want those users to login via Login UI(box) feature of Liferay. Is it possible ?

[David H Nebinger, modificado 7 Anos atrás.]

If SSO is properly configured, they shouldn't see the login form, they would be logged in automagically.

If that's not happening, it points to an issue with your SSO setup.

[Andrew Jardine, modificado 7 Anos atrás.]

I'm in agreement with David -- and I think that your comment and his comment point to the issue with why we haven't been able to solve this one yet. So the questions for you are --

1. Are you trying to configure an SSO solution here (ie. users authentication is handled by another system and they "auto login" into LR?)

2. Which SSO model are you using? (CAS? OpenSSO?, SAML?, OAuth?)

.. if these assumptions are correct, and you have configured something as part of step two -- can you provide us with the details on your configuration?

[G R, modificado 7 Anos atrás.]

HI,

I am developing my own implementation for SAML through AutoLogin. non-omni user are able to login automatically without login box being prompted. Further i have requirement to allow only omni user to login as non-SSO(local) user via login box. But at that point I do not want any other user to be able to login through that login box.

[Andrew Jardine, modificado 7 Anos atrás.]

I understand -- and honestly I think this is a common challenge for SSO. You want to maintain the Admin user in the portal but that user does not exist in the SSO system. Two options I would consider.

1. Add the "Admin" user from Liferay into your external directory store. I know that most people don't want to do this (and I am never clear on why exactly) but this is probably the simplest solution. You are able to specify the screenname for the admin user when you first setup the portal, so it doesn't have to be "test"

2. Alternatively, I have done, for better or worse, a Startup hook that checks for a particular user in the LR db. This is a user that you KNOW should have admin rights (like yourself for example). If the user doesn't exist, create them, and assign them the Administrator role. Since that same user will also exist in your external system then you know that you can log in with them in your OpenSSO (or whatever you are using) and pass through the auto login in the portal with Admin rights.

There is a #3 option of course. Liferay provides a SAML portlet as part of EE. You could license the product and use that one for free

[David H Nebinger, modificado 7 Anos atrás.]

Or #4 - give the admin role to an actual user who is okay to be in the SSO. There's no requirement that an admin must be a separate user, admin is managed by a role which can be given to appropriate users.

[Andrew Jardine, modificado 7 Anos atrás.]

Agreed -- but isn't this where the chicken and egg scenario starts? If you only load the user into Liferay when they first login, then the use doesn't exist to be assigned the admin role until that point right? But then for that to happen you need to configure the portal to use SSO ... but then the admin (test) user is not in SSO.

I suppose if you ENABLED ldap, with all the correct settings but didn't set it to required, and had the SSO feature disabled then you could still log in as test/test after the user is created, grant the role, and then force the LDAP to be required. But this is why I was saying set the default admin screen name to the user name from your sso. So if it was me, and my login was ajardine .. then set the default admin screen name to ajardine. Then I log into OpenSSO, am redirected to the portal and my account is already there with the Admin role.

All this is mute though as G D has already told us that he is making something custom so perhaps it's either on or off for him. The suspense is killing me. I hope he answers soon! ;)

[G R, modificado 7 Anos atrás.]

HI,

Thanks for taking interest in looking. One thing is clear : I do not want omni user(which is default test) to any way related to SSO/IDP system.
So changing the name of omni user to something else and adding it SSO Server is not choice here. A omni user must login through Liferay Login box and no other users but. I did not understand how #1 suggested solve this problem ?

[Andrew Jardine, modificado 7 Anos atrás.]

Hi G R,

I think this is going to be a little tricky to solve and really there isn't a "clean" way of doing it. I'd love to hear some others thoughts but so far the only "creative solution" I can think of is this.

1. Configure your SSO+SAML IdP/SP with LR (assuming LR is an SP in this relationship) -- but don't enable these things in LR (I think you said you were building something custom anyway).

2. Configure at least one public page with the login portlet on it. This is where all users will go to login.

3. User enters the credentials.

4. Create a Pre Login Hook that will look up (using the LR api) the user with the login provided. You probably also need to check for whether or not something else (a token, a parameters something) is in the request to indicate that they have come back from open SSO (Step#6).

5. If the user exists, check to see if they are an omni admin, or have the administrator role or whatever you check is. If they have this role, then allow the Login process (in Liferay) to continue.

6. If they are not one of the admins that doesn't need SSO, forward the user to SSO. It'd be great is you could do this with the credentials provided so that they don't have to login a second time.

... alternatively you could provide a url or a hidden page or something that would be the "alternate" login that would be used to gain access to the admin I suppose. The problem I have will all of these options is that it feels like it's making the whole poral less secure. You want to have a centralized authentication mechanism, but not for "this guy".. but everyone else has to follow the rules. But for him to break the rules you need to poke holes.

I wouldn't really sanction anything above, but it's something you could try.

[G R, modificado 7 Anos atrás.]

HI Andrew,
thanks,

I completely understand your concern regarding providing 2 different types of user ( SSO and liferay local). I did bring this to notice of team while working on. So the one option we think is disable the omni user once done.

I implement something similar, along with rejecting any liferay local user like omni user. The users which are not part of SSO system are put in a configurable property and rejected if they come as part of SSO/SAML flow.

Since Liferay requires password as one of the fields for any new user created, furthter the question(original question) I had was is there a way we can disable the SSO users login (created through AutoLogin) from Liferay UI. The passwords generated are encrypted and auto-generated. I was thinking some flag for user like allow access from login box or AutoLogin feature.

EDIT
I read again your response : I see your suggestion regarding : "Create a Pre Login Hook". I will check on feasibility of it. Thanks !

[Andrew Jardine, modificado 7 Anos atrás.]

Hi G R,

If you concern is the password check and users not knowing the password, or it being different from what is in SSO (because you auto-generate it) you could always disable the Liferay check with this property --

 auth.pipeline.enable.liferay.check=false

.. again though, just one more security hole! Also note that if you end up using a multi-instance configuration (multiple portal instances on the same server) this field is applicable to ALL instances. You basically disable any Liferay based password checking on the server with this setting.