I have a requirement to create Login/Registration/Forgot Password from Database itself in CQ5/AEM.
Login Page
Registration
User Activation
Approval Process
Landing Page after Login- How to configure on Dispatcher
Forgot Password.
7.It should work as User management in CQ5/AEM
I know its a big requirement but if someonr can give me idea to implement it would be big help for me.
Thanks in Advance
Related
I've just integrated my app with IBM's SSO via Cloud Directory. The idea here is that I want access to be very secure and only authorized users (pre-approved) can access the application (e.g. website in this case).
However, I've just realised now that anyone that goes to the app's webpage can, instead of logging in, just select "Register New User" and fill in some details and he's given access? Is there a way to:
1) EITHER keep that registration form, but require one of the admins to approve it before access is given? (better solution)
2) OR completely remove the self-registration option?
As the current situation is far from secure for what I need.
Thanks a lot!
I talked with the support team and that is the best (only) way to do it, just remove the links from the HTML templates.
Can anyone think of a neat solution for this; we operate an website service and sell to large organisations. Rather than have a logon for everyone, we'd like to be able to provide a direct link to our website from the organisation's Intranet page. We'd then like to check the referrer and if it's in our listed of 'trusted referrers', i.e. the intranet url, then we grant logon without asking for credentials.
I'm aware you can do $_SERVER['HTTP_REFERER']; to get the referrer, but I'm also aware that can be spoofed. Can anyone think of how we could achieve what we want, but while also guaranteeing it won't be hackable?
Thanks in advance
It's not exectly what you want, but to make logging on easier and ensure you don't need to store all the passwords you could use, for example, OpenID.
I think that there is no perfect and safe solution for this.
One solution would be to append tokens to the urls. It will work and it will be save, but anyone who knows the link (including token) will be able to login as that organization
Another solution would be to check the source ip. This can be done in different ways *apache, load balancer, app, etc).
Also a combination of token + ip could work (this token for that organization but only if the request comes from allowed_ips for that organization)
A more elegant solution (which I implemented for several big companies) would be to integrate you website login with the active record domain login. It is possible to use the current user window login as login into a website, using domain authorization. If a user is logged in into a domain, when enters your site will automatically login to the website.
This solution is much more easy to implement than it sounds. But, requires Active directory and workstation that connects to a domain to be in the company (this shouldn't be a problem, most of corporations are using windows on workstations and active directory for domain controller). Also is working best on IE only (direct login to the website). On other browsers the domain login popup will appear and user will have to enter again the domain password.
Also, I am pretty sure that can be made to work on linux environments, but I have no idea how.
I want to create several password protected pages for visitors (clients) to my site. I understand about creating Access and Resource Groups and assigning ModX users to that group - but there are a couple of things I do not understand:
How do you set up a login page to access the secure resources?
If I set up a user group for my clients and distribute usernames and passwords, will they be able to login to the back end of ModX (/manager) like an admin does?
Is is better to just use a plugin like DocPassword that just makes pages password protected (no usernames)?
Any help would be much appreciated! Thanks!
I found this which helped me out a lot:
http://rtfm.modx.com/display/ADDON/Login.Tutorials
What I didnt know is that you had to install an add on called 'Login'
A customer of ours has just purchased CQ5 and would like to externalize all of its security. We'd like to use an STS server for SSO and then leverage a custom authorization/attribute provider instead of the CQ5 repository. Ultimately, we do not want to use LDAP in any way.
Here is how we envision this (some pieces already working):
User browses to CQ5 Dispatcher running in Apache
Apache filter redirects user to STS site where login is completed.
User is redirected back to Apache with SAML Claims.
User ID token is placed as cookie into browser. (everything is working up to here)
CQ5 captures that cookie based on the SSO configuration (working)
Problem starts here: From here, we want to call a custom authorization provider for the user's attributes, roles, groups etc...
We have tried to figure out how to do this and can't seem to find the missing link.
Do we need to create a custom login module? Do we need to create a custom principal provider? Do we somehow use the existing LDAP capability in CQ5 but have it call a custom class which leverages the external auth source?
If anyone here has any idea how to do this, their karma quotient would be full for the year if they could share it. I'm not sure if this is a basic thing you do with JAAS or even where to put my classes after I've created them.
We've worked really hard on this so far and seem to be close, but we keep hitting dead-ends.
Thanks so much if you have an idea where to begin!!
-joe
Recent versions of AEM now include the SAMLAuthenticationHandler which allows you to:
Redirect users to SSO to simulate IDP initiated login, or
Allow AEM to perform SP initiated login with IDP
Specify attributes to take from the SAML Assertion and add to the user's profile node (not sure if you can use this for groups)
Specify which groups users should be added to
Set a cookie called request-path that will store the URL the user arrived at, and then redirect them to that location when they're authenticated (ie. deep linking)
This makes relying on the SAMLAuthenticationHandler better than using Apache to redirect. The current version of the handler bundled with AEM 6.2 does not properly set the cookie when using the redirect method, but Adobe does have an updated version that they can provide that will fix that problem.
I normally recommend that clients do not have their own authentication handlers developed inside AEM.
When not using LDAP, this does create an issue where users will not exist until they've logged in. Additionally, when your architecture includes more than one load balanced publisher, it is possible that a user may exist on one server user synchronization.
Try searching the google group for SSO details. Here's one useful post:
http://groups.google.com/group/day-communique/browse_thread/thread/72c235c83a501252/fba4d08a90487156?lnk=gst&q=SSO#fba4d08a90487156
It seems that you will have to implement a custom LoginModule, more information here: http://dev.day.com/docs/en/crx/current/deploying/custom-login-modules.html
Let me preface this by admitting that this is my first webapp and first experience with JSF, so I've probably made some poor design decisions.
Here's what I'm trying to do:
I have a webapp using JSF 2.0, which is accessible through a Facebook canvas. This webapp allows a user to view/manipulate data from a database of sensor readings. On the very first time the Facebook user accesses my app, I ask the user to enter login credentials for the database, then send the user to the home page. Thereafter, the user should always go straight to the home page, since I associate the user's FB id with the database user profile.
Current implementation:
I have the Facebook canvas URL going to a servlet. This servlet checks the signed_request parameter passed by Facebook to get the user ID, and then looks in the database to see if the user has already completed the provisioning process. If the user has done so, he is redirected to the application home page.
The problem:
Most of my logic to do these checks currently exists within a managed bean (session-scoped). To use the bean within the servlet, I'm manually instantiating the bean and adding it to the session, since the JSF framework hasn't had a chance to create it yet. As my system is getting more complicated, this is causing problems due to dependencies between the various beans. Also, it seems like a generally bad approach to the problem.
Solutions? From my web searching, it sounds like there might be several ways to do this. One way would be to set the canvas to a JSF landing page, where a managed bean would grab the signed_request parameter and validate that the user has completed the provisioning step. From there, the bean would forward to the proper page. Another possibility might be to have an eager bean that does the same thing, but this seems "wrong".
What's the best way to resolve this and adhere to "proper" JSF paradigms?
Thanks in advance!
There are a number of different ways that this can be handled. The JSF landing page is one idea and the eager bean are some ways that this can be handled.
If you ignore the fact that you are integrating with Facebook then ultimately you are trying to solve an authentication and authorization problem. Facebook is handling your authentication, and telling your web application what the identity of a user is, and it is your web app's job to remember that person's identity throughout the session, and authorize this person to visit the requested page.
I have implemented it before where I had all of my managed beans extend a BaseBean class that on creation and initialization checked for the existence of a specific SessionScoped bean that contained the user identitification information. If this bean did not exist or was not authorized to access this bean then I would redirect. The problem with this approach was that it authorized only the use of managed beans, and not pages.
Another approach I had was to utilize a servlet filter that would essentially check every page request and look for the session scoped bean that contained the currently authenticated user. If this wasn't found then I would look for the specific request parameters and authenticate and create the session bean, and if that didn't exist would redirect to an Unauthorized page.
This approach worked well until I realized that Authentication and Authorization of Java web applications is a well understood and near universal problem. After a little bit of looking and research I discovered that security frameworks like Spring Security 3 can indeed be integrated into JSF and handle nearly all of the complexity of complex authentication and authorization. You could very easily integrate a custom Facebook authentication handler for Spring Security and control access by user role to the individual page level, all from XML configuration. It is highly worth looking into if you have the time to learn something new.