The J2EE Application implementation will propagate credential to EJBContext automatically. It only includes user name instead of password, right? What's the standard way to propagate for non-J2EE system? I need the user/password to login another system in server side (kind of SSO). I can put user/password into ThreadLocal. Any cons for it?
ThreadLocal won't work since authenticate and application are not same thread. I figured out one way that put customized principal into Subject and load it from application side. Not sure if it is right approach to support SSO since the plain password is set into subject.
I figured out one way that put customized principal into Subject and load it from application side. Not sure if it is right approach to support SSO since the plain password is set into subject.
Related
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.
We're trying to evaluate a solution to implement "true" SSO for multiple (already existing) web solutions. True SSO here means to login on any service, and be authenticated on all, without further actions from the user.
All of the applications we're going to use support OpenID and/or have plugins that allow OpenID, so this seems like something worth looking into. However, as I understand OpenID, the users would still be required to enter their OpenID credentials in each service.
Is there a sane way to implement SSO with automatic login once the OpenID provider has authenticated the user?
In an earlier project, we hacked up the PHP session data in the login procedures of two applications (both running on the same domain and server) so a login in the first application creates the session data for the other application as well. However, this is a very hacky solution and is prone to break when either application is updated, so we're trying to avoid it this time.
Are there any other SSO solutions that we could look into?
i am assuming that you have the control on the SSO implementation
there are some things you can do to make sure that once the user has been recognized by the SSO application, he will virtually automatically be logged in to your other applications
in your SSO application, create a whitelist of service providers. authentication request from those websites will be automatically approved. thus, user won't be asked to approve the request manually
in your application, set the return_to parameter as the page the user is intending to immediately open. don't simply set the return_to to that application homepage
by the way, the most standard openid implementation accepts any url. however, if you want to use the sso in a controlled environment, you can set the service provider to have a whitelist of trusted identity providers. after all, it's the service provider which initiated openid authentication.
Yes, there is a means to do this. Run an Application Server, Node Based, and register cross-domain techniques to offer cookie-credentialed (backed up by site-handshakes as each new user arrives, to scale better and minimize resource expenditure per-session).
I am working on such a beast right now, and I'm 5/6th done.
I have taken care of several annoying variables up front- including the means to assure unique user logon- and I've taken a stand on other issues- one just can't get everything done in one system. However, one can have a true SSO if one is willing to pull out some stops. It is YOUR stops which will define your solution. If you have not accurately portrayed your limitations then there isn't a solution which can be offered for implementation here, and the nature of your problem is ENTIRELY implementation- not theory. In theory you have 4-5 different options. In practice you will find your answers.
Basically, I have the following scenario and information:
We're using HTTPS.
We want to authenticate a user by user/pass when they first log in.
After they are authenticated, I want any future calls to OTHER services (not the login service) to use the username and some sort of session (in case the password changes in the middle of a session).
I want to make sure my sessions can timeout and control them in a way that if a user tries to call a service and they don't have a session they get an error (cause they haven't logged in). Not sure if there's a WCF built-in way to do sessions this way or if I'll have to do something customized with a database.
I think we want to use WSHttpBinding (not BasicHttpBinding), 90% sure on this.
I just can't seem to figure out how to do this. Often time's I'll find information on the client code doing client.ClientCredentials.UserName.UserName = username and client.ClientCredentials.UserName.Password = password. But, that just doesn't work because what is my server checking against? I'm trying to grab that info and validate it against a database of user/passes. I'm not looking to use Windows Authentication or that sort (because I don't care who is logged into the computer, just who is logging into the app).
You want to use a Secure Token Service (STS) to authenticate and get a Security Token (maybe SAML) back that identifies the user which can then be passed to your other services and they can just use the identity information to identify and authorize because they trust the STS has verified the user's identity up front.
This is a large subject to discuss, so I suggest searching for WCF STS and doing some more research, but that's definitely the direction I'd recommend going. If you're going to build your own STS implementation, I also recommend looking into using the Windows Identity Foundation (WIF) components to ease your development efforts.
Here's the download link for WIF v1.0 which is the latest version at the time of this answer.
I'm working on a password management system which stores the passwords of a bunch of services (gmail, bank of america account, youtube etc). The user will be able to launch each of these services by logging into my application. The application will then POST the username and password associated with that service to that service's login url in a new tab and you will be immediately logged in. My question is, this method exposes the actual password of the user to the client side (since I'm creating a form with username and password, in plain text, as hidden fields and calling form.submit). I'm wondering is there any other method by which this can be achieved? How do all the password management sites work? Your help is appreciated.
Do it server side, what else can I say? Anyway, I can only see this as a learning experience, not something that would eventually go into production. cUrl could be a good start. Why do you use form.submit anyway?
This is called "formfill" in terms of access management terminology, if you are thinking about access gateway (http). If you are thinking about browser plugin, have a look at the firefox autofill plugin. And which finally reduces to single sign-on.
Single sign-on are done different ways,-
some servers uses active directory to store all the passwords and later access using the master password , i.e. the active directory password of that user to access his credentials.
Some uses SAML
Some uses e-directory
Whatever you use, if it is server-side application (e.g. Appache supports formfill), it parses all the forms based on form name or resource path and fills credentials based on the authenticated session from the user.
Disclaimer: I'm not a Notes admin, I just wrote the application :), and I try to help our client to use it.
We provide a simple database with one agent to accept and process HTTP POST messages from Internet.
The Domino server where this database is going to be installed is configured for Single SignOn authentication for web access.
Is there a way so set only our database to use different type of authentication - i.e. Basic Authentication, so we can hit it like this to POST messages to the agent:
http://username:password#my.domino.server/mydb.nsf/myagent
I thought about another approach as well - to remove any form of auth, and pass the credentials in the POSTed data itself. Then the agent will take care to process or not the data, base on if the creds are OK. But this most probably will require some form of "impersonation" - I.e. to map somehow the anonymous user to the one, which has the rights to execute the agent. So, I valid answer to this question may be an advise how to set this up.
Additionally - we are looking at the web service approach (available in Domino 7.0+), but it will require changes on both sides - the sender (our publisher service) and the receiving agent. And most probably will lead back to the original question about how to authenticate the sender.
Any advice in that regard (even changing the approach) will be highly appreciated.
Cheers
Since Domino 7.0.2 there is a new kind of website rule entitled "Override Session Authentication" that allows you to specify, for a specific URL pattern (ex : /folder/myapp.nsf/myagent?*) to use BASIC auth even if the whole server is configured for session-based auth.
This was initially introduced for RSS readers (that cannot handle sessions).
More information here :
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.help.domino.admin.doc/DOC/H_OVERRIDING_SESSION_AUTHENTICATION_8847_STEPS.html
Although it's horribly insecure to allow this, it is possible using web site documents on the server.
Create a website document that has basic authentication for your database (it will need it's own domain name) and then everyone else can access the server through the default website document which uses session authentication.
I'd suggest adding Anonymous to the ACL of the database, with No access and nothing but Read public documents checked. Then, you can grant access to the agent by checking Allow Public Access users to view and run this agent in the Agent properties.
I don't know if it is possible to get the Authorization header into the agent to check the authentication. If there are only two parties communicating I would compute a hash of the message, a timestamp and a shared secret and use that to check access.
Edit
You won't be able to parse the Authorization header manually. Domino (at least 7.0.3) tries to do a session authentication if your request contains an authorization header, regardless of access settings on the object you request.
Here, put that URL in your Favorites toolbar :
http://www-01.ibm.com/support/knowledgecenter/SSKTMJ_8.5.3/welcome_Domino_8_5_3.html
Also did you know that your Notes client and Domino Server come with help databases full of very adequate documents ? Try the [Help] menu for starters.
Then, said help databases are usually in the aptlty named "help" folder". Open them.