We are hoping to use multi-tenancy feature of Liferay for a new implementation.
In the past versions of Liferay (prior to 7), we have been able to integrate and protect each instance of Liferay separately using Siteminder (under Control Panel -> Portal Settings -> Authentication -> Siteminder).
It seems that with Liferay 7, this is no longer possible. The Siteminder SSO configuration has been moved to with the default instance only(?) by using the token based SSO and ability specify the SSO auth request header. There does not seem to be any way to do the configuration for the secondary instances in the control panel.
Is anyone using Siteminder SSO with Liferay 7? If so, has the token based SSO worked for the default instance (ex. abc.com)? Has anyone used this for the secondary instances (ex. xyz.com)?
Any insight is much appreciated!
Thanks
Try to export the configuration and put the config file into the osgi/config folder and append the name with the company ID com.liferay.portal.security.sso.token.configuration.TokenConfiguration-20116.config (or cfg)
If this does not work the reason is that somebody forgot to add scope = ExtendedObjectClassDefinition.Scope.COMPANY to TokenConfiguration
An option would be to override this class and add the scope. I'm just afraid that a helper would then be required to pull the company-specific configuration.
In this helps someone. I heard below from Liferay. I will be testing and will post an update:
Token Based SSO has been elevated to a system setting in Liferay DXP.
This means that when the feature is enabled it is available for every
instance. There is no longer an option in Liferay itself to provide
instance-level support for Token Based SSO. The SSO is
enabled/disabled for every instance because it is set at the system
level.
Liferay DXP only cares that a token has been provided. What this means
is that whether the token is for the right instance is up to the
authentication servers being used. It is conceptually possible for
each instance to be able to use its own token. This can be tested by
seeing if the authentication servers lead to the right instances when
they provide their tokens. If that does not work then modifying the
authentication servers to ensure that they are providing the right
tokens to be directed to the right instance may be the next best step.
In regards to whether or not each instance can be individually
protected, because Token Based SSO is enabled at the system level if
instance level authentication is also enabled then both
authentications would be hit during the log-in process. If Token Based
SSO is set at the default security feature and the instance-level
authentication as the secondary, then each instance can be
individually protected.
Related
I have a web app running on weblogic 10.3.
Is it possible to make sure, that AuthenticatedSubject is always in place for all resources? Ideally by setting some default authentication for all apps, so that I dont have to modify every application's security settings.
Can I enforce, that the user has to authenticate himself once and to keep him as a principal for each request?
I tried to set up an authentication-provider in my applications realm, but it is not triggered.
I think I have to say weblogic, that all resources have to be protected in my realm.
How would I do that?
Everything is explained in this document : https://docs.oracle.com/cd/E13222_01/wls/docs103/pdf/security.pdf
You have to configure your web-app with a secutiry contraint to protect your application and force users to be authenticated
I'm a newbie in the LDAP + Liferay + OpenAM world, so I wonder if someone could point me in the right direction in a problem I have. In a real life environment, there are 2 LDAP servers, a OpenAM server and a Liferay application. What the customer needs is to authenticate users in Liferay against OpenAM, and OpenAM should use the LDAP servers. Problem is, the user exists only in one of the LDAP servers (it will be moved from one to the other in one point of the future). What the customer wants is:
Users must be able to authenticate independently of what LDAP contains the user.
The obtained token must be valid for both LDAP servers, as it will be used in a different service (I have no control over it) against only one of them to validate authentication.
As I said, I'm new to this world so, if the answer is too complex (I'm afraid it will be for me), maybe you could point me to books or docs that could resolve this scenario.
Thanks
You should configure LifeRay to use OpenAM for all authentications and you can configure OpenAM to use both LDAP servers (use different realms).
Details for OpenAM configuration will be in the OpenAM documentation.
As the previous answer states you should route all your authentication requests to the OpenAM server and let it validate the credentials against the right LDAP server. Using two different realms (one for each LDAP server) won't work in your case since that will require LifeRay to know where to find the user before hand. Also, sessions are linked to a specific realm.
There are multiple solutions to your problem. Here are just a couple:
Option 1
If you have control over the authentication flow. That is, if your application uses a custom UI and communicates with OpenAM via REST, you could create two different authentication module instances under a single realm (let's say two instances of the DataStore authentication module) each one pointing to a different LDAP server.
Let's call this module instances DataStore1 and DataStore2. Your application can collect the user credentials (username and password) and submit them to DataStore1. If authentication succeeds the user is already logged in. If it fails, the application can try with DataStore2.
Of course this is not ideal since you'll be making two authentication requests per login instead of just one.
Option 2
A better option (though more complicated to implement) would be creating a custom authentication module. This module can try authenticating the user against LDAP Server 1 and then try with LDAP Server 2 if the first authentication failed. Notice that with this option you don't need custom logic on the application side since it will only send a single authentication request to the OpenAM server. In fact, you can protect your application with an OpenAM Policy Agent.
Another advantage of this approach over Option 1 is that you can migrate your users behind the scenes assuming that the end goal is to migrate users from LDAP Server 1 to LDAP Server 2. If the first authentication succeeds your custom code could read the user entry from LDAP Server 1 and copy it over to LDAP Server 2.
Hope this helps you solve the problem.
This is all with v8.2, with plan to migrate to 9 at a later date
Here's what we're looking into. To access one folder, users would need have AD authentication, for two other folders, user would need to authentication via Kentico's user management. The rest of the site would be wide open.
We also need to ensure any bookmarked URLs send the user to the correct authentication method, if applicable.
I'm digging further in to the documentation for this too.
Yes this can happen. You'd need to enable/setup Mixed Mode Authentication within Kentico.
Secondly, for ensuring proper access to specific nodes in your site, I'd default to whatever more pages need; either require authentication or not. So if the majority of your pages required authentication, then on the master page level in the Properties>Security, set Access to require authentication. This will then propagate through the rest of the site.
For each of the nodes which are "public" simply go to the parent node Properties>Security and set Access to not require authentication.
I have an OpenAM Identity management and a website that needs its credentials for loggin in. I want to federate my website with Google. My web site doesn't support any Federation protocol. How can I do this? Is there any module or plugin for each protocol to deploy in my site? should I change my source code ?
You should potentially set up federation between Google and OpenAM, and then use a policy agent or OpenIG to protect your application.
Even though both the agents and OpenIG tries to make the integration as transparent as possible, it may be necessary to modify the application (for example to ensure that the app reads the user name out of an HTTP request header/cookie/etc, and possibly some other modifications to interact with the application's authorization framework).
I am trying to protect a Java servlet with OpenAM + J2EE tomcat agent. I got this part working by using embedded OpenDJ of OpenAM.
Now I am trying to authenticate against a LDAP server, so I added a LDAP module instance for OpenAM, but I get "User has no profile in this organization" when I am trying use uid/password of an user from that LDAP store.
I checked OpenAM administration guide on this the description is rather brief. I am wondering if it is even possible to do this without using the data store configured for OpenAM?
The login process in OpenAM is made of two stages:
Verifying credentials based on the authentication chain and individual authentication module configurations
User profile lookup
By configuring the LDAP authentication module you took care of the authentication part, however the profile lookup fails as you haven't configured the user data store (see data stores tab). Having a configured data store allows you to potentially expose additional user details across your deployment (e.g. include user attributes in SAML assertions or map them to HTTP headers with the agent), so in most of the scenarios having a data store configured is necessary.
In case you still don't want to configure a data store, then you can prevent the user profile lookup failure by going to Access Control -> <realm> -> Authentication -> All Core Settings -> User Profile Mode and set it to Ignore.
This is unrelated to authentication but it's related to authorization ... you have to configure appropriate policies ... see OpenAM docs.
Agents will enforce authorization, OpenAM determines if the user has the permission to access a protected resource.
As Bernhard has indicated authentication is only part of the process of granting access to a user. He is referring to using a Policy to control access.
Another method is to check if the authenticated user is a member of the desired group programmatically. This can be useful when you want access control over resources that OpenAM doesn't know about (e.g. specific data).
For example, lets say that you want different groups to have access to different rows in a table in a database. You can retrieve the group information associated with the user and add that to your database query, thus restricting the data returned.
I'm sure that you could do this with OpenAM as well using custom modules to allow the policy to use information in the database as resource, but I've found it is much simpler to perform this fine grained access control in your code, and is in all likelihood significantly faster.