Has anybody had any success creating an XPage application that includes SSO so that the user logs into notes client and is able to open an XPage application (Database) which uses the Social Enabler to integrate Connections data into the XPage? The key to my projects success is to not need to prompt the user for their username and password (The user has just logged into notes!).
I have seen #nheidloff blog about SSO using the LTPA token between an xpage and connections, however I need this to work within the notes client. If anybody has any success in creating this, can you share any tips please.
I have blogged about a technique...
http://lotusnotus.com/lotusnotus_en.nsf/dx/authenticating-notes-users-for-web-apps-automatically....htm
To sum up, we need a LtpaToken for web-based authentication. We have ability to create an LtpaToken inside Notes client using a Java method of the session object. So my solution has two parts.
A java agent that produces a valid LtpaToken for the authenticated user on the client side. We are calling this java agent from any Lotusscript routine.
The second part is a redirection web page on any database that can be accessed anonymously. This might be a Lotusscript agent, servlet or XAgent. It will get LTPAToken and a target URL from a GET request, add the LTPAToken into cookies and redirect the user back to the target URL.
In Lotus Notes client, any Lotusscript action might call the Java agent, acquire a valid LTPAToken and launch a constructed URL which points to the redirection web page with necessary parameters.
There is a couple of bugs I have detected on Domino Web server. For details of the technique and workarounds about these bugs, you might refer to my blog entry.
Related
I want to create a web page, that will serve to authenticate users based on credentials I give them (user1, pswd1 etc).
Only after a user authenticated, he should have access to a few other web sites,
on different folders of the web server, but which have no server side code(otherwise it would be simple.)
The user should be allowed access to the other sites, e.g. based on his IP,
for 24 hours or another period, or while he has the authentication site open on his browser.
The purpose if that the user will not have to enter credentials on each site,
and will enter his credentials only once, or once a day.
Restrictions:
I don't want to modify the target web site javascript code at all, e.g. to query a web service.
The user should be granted access using any browser,
so I assume I cannot use cookies.
If I would develop such a mechanism on Apache,I could, for example, have the authentication site PHP code add a line "Allow from ip" to the htaccess file of each target web folder, whenever a user authenticated successfully.
The issue is that I don't want to develop it as I am sure a solution already exists, and also I need a similar mechanism for both Apache and node.js (although i can live with two different solutions)
What information does the user have to identify themselves? How do you guarantee the user is who they say they are?
The whole point of authentication is to establish the user is who they say they are and that may create a session so that users need not reauthenticate.
If you want the user to authenticate in a single location and then reuse that "session" or set of credentials elsewhere, what you are looking for is single-sign-on / identity federation.
For instance, take airbnb.com. I do not need to authenticate there. All I have to do is authenticate with a third-party e.g. Google or Facebook. As a matter of fact, SO works in the same way.
One of the standards behind this technique is called Open ID Connect. Look into that. If you are willing to dish out money, you can look into commercial solutions e.g. Ping Identity. There is an open source implementation provided by Mitre / the MIT. It's available here.
In fact it occurs to me I can use simple routing.
In the top level folder have php code that does the authentication.
If the user is authenticated, route/redirect to the requested target site,
based on the requested url.
The url should be for example http://mysite/site1, where the authentication code is in the folder mysite, and site1 is not directly accessible.
Perhaps I can use something like php-express to reuse the same php code on node.js.
I have been working on IBM Maximo Anywhere apps such as Work Approval and Work Execution for sometime now have few queries regarding the login mechanism used by these apps. To be specific as per my understanding anyone having access to maximo on that particular environment can login into the anywhere apps - is that a correct statement? and if yes then how does it work in a disconnected state? If for any reason maximo is down will it mean that the app will not be able to authenticate a user and hence unable to login as well? And alongwith that is there any other kind of authentication done for example LDAP etc? Are there any different kinds of login failure messages that are displayed depending on why the app isnt able to let the user login? or is it a common one saying "Login Failed"
The first time the user ever logs into the application, they do have to have a connection to the Maximo server to authenticate. We also validate that the user is authorized to use this particular mobile app. We have a security group for each mobile app that the user must be a member of. After the authentication and authorization finishes, we download, store, and sign the locally stored data with the username/password combination, so that on subsequent login attempts, if the server is down, we can fail over to the locally stored data. This also guarantees that the locally stored data is protected.
We support all of the types of authentication configuration that base Maximo supports.
More information here:
http://www-01.ibm.com/support/knowledgecenter/SSPJLC_7.5.0/com.ibm.si.mpl.doc_7.5.0/security/c_authentication.html
I tried to do some research on this matter but couldn't really find anything. So, I was just wondering if anyone ever did something like this or if it would even make sense to do it that way:
Lets say, you have a secondary NAB for users who don't have a notes ID but need access to your web-enabled Notes / XPages applications.
Now, a non-notes web application wants to allow the same set of users access to their application.
Could this application use the Domino Web Login, so, user can log in into the non-notes web application?
How would a redirect work after a successful / failed log in attempt?
Would you use JSON / WebServices for that, or how would you implement it?
I know it is a rather general question, but I was just wondering.
Any response would be highly appreciated.
Thank you.
Daniel
If the other server can use LDAP for authentication, then you can configure Domino's LDAP task and set up Domino's Directory Assistance to expose your secondary address book to LDAP, and configure the other server to use the Domino LDAP as it's authentication source.
Note that this is not a single sign-on solution, so separate login will still be required for the non-Domino application. It does get you a single authentication source, though.
I think that I have configured web SSO (SPNEGO) on our test 8.5.3 server. I created a test discussion data base and when I access it with a web client my credentials are displayed. But if I acces my Xpage first the #Username function shows Anonymous. If I display the discussion page first then return to my Xpage the #Username gives the correct name.
Any ideas ?
I would check the ACL of the databases and see what anonymous is set to.
I suspect that in the discussion anonymous is set to 'no access' so it triggers the login process via SPNEGO and logs you in with your credentials but the XPage app may have anonymous set as reader so it is just letting you in as anonymous.
When you access the discussion before the xpage app the ltpatoken SSO cookie is being set so when you hit the xpage app it knows your logged in via SSO which is why it is showing the correct credentials in that case.
I am creating a web application that uses the Drupal 7 Content Management System. The web pages heavily use JQuery and AJAX.
The AJAX calls hit REST services, which are actually implemented using JAVA. Apache is running Drupal 7 and is configured to pass any calls to the REST urls through to the Java EE server (Jboss AS7). Everything is over SSL.
I need to Authorise and Authenticate calls to the REST services, and access the username or ID of the person currently logged-in to Drupal from the Java app. The question is... how...
As the AJAX calls are made to the same Apache server (rather than to a separate server etc), everything happens within the same http session, so I'm hoping this will be quite easy.
Things I've thought-of:
Configure a java security interceptor that calls a custom (locally
accessed only) drupal service that somehow reads the session id and
returns the logged-in username
create a "dumb" drupal REST service to act as a gateway for all of my REST calls, which authorises/ authenticates then injects the username before passing-through to the Java backend service
The article at https://lists.wisc.edu/read/messages?id=7777296#7777296 made me wonder if I could get-away with calling a Drupal service (just at the start of each Java service session) that takes a Drupal sessionID and returns the current user and his roles. I could configure it in my Java service so it would reperform this call every x seconds or y calls to check for role changes or logouts.
How does everyone else do it? This must be a common problem to solve isn't it? If not, what do you do instead to securely access authenticated services over AJAX? I'd rather not introduce a second user control process in addition to Drupal unless it's unavoidable. DRY :)
Thank you - this has me stumped!
Looking at what you are doing and trying to keep things as simple as possible, I would go for a variation of the first option. This is basically what the current node.js module does although it does it with unique authorization tokens. The workflow is something like this:
When a logged in user loads a page, a unique token is generated and stored in the Drupal database and sent to the browser
When the browser goes to connect to the node.js server it sends the auth token along with the request
The node.js server, upon receiving the request with token for the first time, will connect to a web service on the Drupal site and verify that the token is valid and send back any info about the user, and what roles/etc they have.
The node.js server then stores this internally for future requests, so that it doesn't have to ping the Drupal site for each request.
When a user logs out of Drupal, Drupal makes a direct request to the node.js server asking it to delete the token for that user.
Sounds like basically swapping your java app for node.js this should be pretty doable, with the advantage that it can scale well if you split this to multiple servers in the future.