I have a custom web "portal" that is essentially a webapp built primarily using JSP/Tiles, Spring/MVC, and Hibernate. It runs on an Apache/Tomcat, MySQL stack. I have the portal within quotes because this is not truly a portal in the same sense as a Liferay, Glassfish or whatever portal server. But essentially what looks like a portal to a business user and one that pulls in data from several 3rd party systems through custom system integration.
I am now looking to add a community module to this "portal". A key piece of this requirement is to federate identity between this "portal" and the community server. Further, to facilitate a seamless single sign-on from the "portal" to the community. My preference is to keep the choice of community software to java-based and open source. Liferay is one example of it. JForum is another though it is limited to just discussion forums and not other modalities such as blogs and wikis.
Presently, the custom "portal' provides its own authentication/authorization mechanism based on user information in the MySQL database. It appears that for a scalable and flexible account provisioning across multiple systems, I am better of refactoring this to be based on a CAS-based authentication supported by a directory server such as OpenLDAP. It seems like with this approach I might be able to integrate with a community server such as Liferay.
If I extend my choice of community server to a PHP-based solution such as Drupal, can I accomplish the same result through a CAS-based approach? Any recommendations on how to federate identity (and enable SSO) between a custom Java webapp and Drupal? Entry point (login) for a user to the community will only be through the custom "portal".
CAS is a very popular method. Here is a Drupal module to support SSO into a Drupal installation.
Related
Has anyone implemented a project using Azure for user registration and authentication?
I can see how it would work well in an Enterprise application, but it seems as if there is no easy way to enable "self registration"
It looks like it is intended to work with an on premises AD solution, or alternatively for new users to be added using the Azure management portal.
Can anyone give me the benefit of their experience?
WAAD is a fully implemented solution for what I think you are trying to do, but created in a way very different than the "Active Directory" server product that it shares a name with. Take a look at the Windows Azure Active Directory Graph API, which is the RESTful management API for WAAD. With Graph API you would be able to create a fully functional application authenication system to meet your needs.
Overview
http://msdn.microsoft.com/en-us/library/windowsazure/hh974482.aspx
API Reference
http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx
Links, Examples, etc
http://msdn.microsoft.com/en-us/library/windowsazure/hh974476.aspx
We have some portlets which are JSR 286 complaint. We sell those portlets with a liferay-server to our customers. One customer asked if it's possible to use those with Drupal instead of Liferay.
I can not find any information that Drupal supports jsr-286-portlets. So its not possible to use the liferay-portlets with Drupal, correct?
I think you may have the following options:
Web Service for Remote Portlets 2.0 (WSRP)
Quoting from WSRP specification:
The Web Services for Remote Portlets specification defines a web
service interface for accessing and interacting with interactive
presentation-oriented web services.
Basically you need a running instance of Liferay exposing your portlets as presentation-oriented web service to Drupal that will consume them and send back to the client.
The good news is that Drupal seems to support it. You need to enable Drupal as a consumer of WSRP, see that Drupal page, and Liferay as a producer, see here.
Using IFrame
Similar to first solution but with less integration and more work to do about security because the client will contact directly the Liferay server, so you'll need to expose it as a public server (if not in a Intranet scenario) and you'll probably need a Single Sign On solution for authentication.
I suggest to take a look at that document about Liferay Application Integration Strategies because recap very well several integration strategies with pros and cons (including the two I cited).
The project has a situation which can be described as: a portal application has to be built. This is expected to be home for many existing non portlet applications (some are Java EE based and some not).
Obviously, portal will provide SSO. Options of rendering a non portlet application to portal seem to be using either an iFrame or a URL redirect. In either case, it looks like the request has to pass through the portal server (??).
What are the challenges that this solution face? Best practices to get this implemented?
This is what a Portal solution has been meant to provide: central point of access to applications, services, people, processes...
There is also the third option for integrating legacy web applications (I assume you are asking about WebSphere Portal Server) and that would be "Web Application Integrator". You can find some info on it here
Challenges with this solution would be related to:
1. SSO - there could be some complications with this, depending on infrastructure.
2. Look and feel uniformity - Portal themes should be appropriate for web applications to be integrated.
3. In some cases Web applications will need to be changed in order for integration to be possible.
Yes, each request will need to pass through Portal Server.
Hope this helps..
I have a website that uses ASP .Net membership and roles using the SqlMembershipProvider and SqlRoleProvider. Right now I am only using this for a small section of the site that only 2 people have access to. The site may expand in the near future and the number of users could grow into the thousands.
My question is, is there any kind of open source administration tool for managing users or am I stuck building my own? I can't really use the ASP .Net Web Application Administration Tool because, as far as I know, it is only accessible from Visual Studio. User administration would be handled by our help desk and would need to handle all of the things that the stored procedures in the SQL server provide such as adding users on the customer's behalf, resetting passwords, unlocking users, etc.
I just can't believe that an administration front-end has not been developed to handle these sorts of things and provide more functionality than the ASP .Net Configuration page provides.
Take a look at MyWSAT on CodePlex.
http://mywsat.codeplex.com/
MyWSAT aka ASP.NET WSAT is a WebForms based Website Starter Kit for the ASP.NET Membership Provider with Forms Authentication. It provides you with all the security features required for a site out of the box so you start focusing on building your pages. It allows you to manage membership users online once your site is deployed. It features complete administrative back-end functionality and designed to manage users, as well as admin pages for users to manage their own user data.
We have many custom built web applications (both external & internal) written in Classic ASP and ASP.NET 2.0 technologies. Internal users can upload files to these websites, which can then be viewed by External Users. In some cases, external users can upload documents as well.
Screenshot #1 gives a brief idea about the existing architecture.
Internal users upload documents to custom web applications. These documents are stored in a folder structure defined under the web application.
Meta data and user permissions like who can access the documents are stored in SQL Server database.
The same set of documents that are being uploaded to custom web applications also exist in SharePoint. However, the custom web applications are unaware of SharePoint. So, users have to download them from SharePoint and then Upload it to the custom web applications. We are currently using SharePoint 2010.
External users can also upload documents to the custom web applications. The meta data and user permissions of the document are saved into database based on the user who is uploading the document.
Screenshot #1:
Screenshot #2 shows the architecture that I am trying to achieve. I have done very little SharePoint development. Mostly, I have used the SharePoint web services to retrieve some list content but nothing more than that. Our future Custom Web Applications might be written using ASP.NET MVC. Please find the questions after the screenshot.
Screenshot #2:
Here are my questions:
I would like to have internal users continue to upload and maintain their documents in SharePoint. User security model is already defined in the SQL Server database. This security permissions should be available in the SharePoint document properties so users can choose who can view the document from the custom web applications. How can I achieve this? Should I have to copy the SQL Server user permissions info to SharePoint?
I believe that SharePoint Web Services or Business Connectivity Services (BCS) can help in retrieving the document and its related info from SharePoint. Which one of these would better suit this scenario?
Custom web app should display only the committed versions of the documents. If a user has checked out a document in SharePoint to make any changes, that checked out version of the document should not be visible to External users. Is that possible?
Has anyone tried this approach? Are there any pitfalls with this model? Are there any performance concerns with this design?
Will this design be of any hindrance if I rewrite our existing applications using ASP.NET MVC?
Is it possible to make use of SharePoint search feature within the custom web application (ASP.NET Web Forms / ASP.NET MVC)? In other words, can I send search criteria from custom web app and have SharePoint do the search and return the results back to custom web app?
I really appreciate your inputs.
Thanks in advance.
Question 1
Hard to say without having more details. So I'm going to assume that you currently use Active Directory for your authentication store. So this means that your SQL Server defines a list of roles and then has assigned memberships to these roles. I'm going to assume that your assigned membership is to AD users or groups. If this is true then I think your on the right path to push your permissions from SQL Server into SharePoint. SharePoint's API will accommodate what you need to do, however SharePoint has no built into mechanism for syncing your permission changes so that means you end up writing a whole lot of plumbing code. I would recommend that you research products that can handle the synchronization for you. Microsoft MIIS (I believe it is called Forefront Identity Management now) offer a set of architecture patterns that you should investigate.
Question 2
SharePoint Web Services or the SharePoint Client Access Services should work fine. I would highly recommend that use a proxy pattern to isolate your application from SharePoint calls (so you can isolate your application from SharePoint upgrades and potential content management server changes).
Question 3
Yes, that is possible. If you are using the publishing features of SharePoint Server (NOT SharePoint Foundation) you will have an easy way of identifying the current published version. Otherwise the service account you query with should be setup so it can only read published versions then SharePoint will automatically trim your query.
Question 4
I have not personally tried this design, but I really like the concept of creating a content management domain and then putting an abstract service layer on top of it. Will you have scale problems, depends on how you configure SharePoint and your applications. You can do it right or wrong. An depth answer between the two cannot be covered here. My one piece of advice is to make sure you plan for caching in your service interfaces (cache, cache, cache).
Question 5
Not if you implement it as a Service Layer. You would just use a repository pattern to call the service and return back entities for your model.
Question 6
Yes, Search is exposed via an API so it can be wrapped in a service layer too.
Good luck and feel free to contact me directly for more in depth discussion.