Re: [uportal-dev] Proposal: Enhance the LoginServlet to accept credentials from request attributes as well as request parameters

[Andrew Petro]

Drew, The change you propose seems harmless.  As you note, request attributes are server-side read only. -1 for ternary operators.  Write out the if statement so mortal developers like me can understand what's going on, please. Once you've written out the if statement, maybe take a look at how to handle the case where the (String) cast fails.  I can see that causing authentication failure.  I'd hate for it to cause the whole render to fail. As discussed at the uPortal dev meeting at JHU, I'd like to see uPortal eliminate all of its non-portal-domain-specific authentication code.  As you note, this model of request parameter username and credential tokens is pretty limiting.  We've found that our security.properties file format is pretty unusable -- Eric did some enhancements to allow you to feed different parameters to different security context factories, and that works, but it looks pretty dated.  Order of operation of security context factory plugins is ill defined.  There are more than a few authentication mechanisms for which well-baked SecurityContextFactories don't obviously exist. There's just an accumulation of needs and problems that indicate that it's time to re-work this piece of uPortal in light of what we've learned.  You've got a band-aid.  It's a clever band-aid, and it will probably help a lot.  My vote is go ahead and create a Jira issue, put this change into /trunk towards 2.6, into 2-5-patches, meet the needs of your client. However, I think the project needs an amputation here more than it needs a bandaid. Fortunately, JA-SIG *does* have a project that has invested *a tremendous effort* in exploring the domain of user authentication and integrations with interesting ways of authenticating users. My proposal is to embed a CAS server in uPortal, which *is* designed to support all sorts of authentication strategies, has a plugin architecture, etc.  How many different LDAP authentication provider implementations should JA-SIG be maintaining?  If we standardize on CAS as the API for this and LDAP-authentication-enable uPortal by LDAP-authentication-enabling an embedded CAS server, then there's only one such API to maintain and only one configuration language to document. Would allow retirement of a good chunk of uPortal code and replacing it with code that's among the best code available for this domain. And in answer to your specific needs, Drew, this would allow you to implement your integration with a home-brew SSO in the form of CAS API authentication handlers and resolvers.  And maybe your needs still push the envelope on what CAS APIs are prepared to do out of the box -- but then that exploration of the authentication domain will be happening in a project built around that domain. Vision for uPortal 2.7 was discussed a bit at the JHU dev meeting; the minutes should be available soon. Andrew Hey everyone, I'd like to make a change to org.jasig.portal.LoginServlet -- the piece of code that orchestrates a login in uPortal.  I'd like to make this change in rel-2-5-patches and in trunk. I'd like to change line 194 from...   String parmValue = request.getParameter(parmName); To instead be...   String parmValue = request.getAttribute(parmName) != null ? (String) request.getAttribute(parmName) : request.getParameter(parmName); My motivation is that, as it stands, authentication in uPortal can only accept information from request parameters.  Per the Servlet API, request parameters are read-only.  Therefore anything I want to examine in a SecurityContext implementation (viz. in the authenticate() method) *must* come across from the user's browser as a URL parameter or a form field. By contrast I can set request _attributes_ in a servlet filter.  The change I propose, therefore, would allow servlet filters to communicate with SecutiryContext implementations, and opens the door to a host of new, flexible approaches to authentication in the portal. For example, imagine I wanted to allow users to type in friendly-looking usernames like 'awills' or 'apetro'.  But behind the scenes the authentication mechanism prescribed by my institution requires an employee_id instead.  This change would allow me to translate 'awills' into an employee_id in a servlet filter (via db lookup perhaps?), then pass employee_id to a standard SecurityContext implementation as a request attribute. I also suspect this change will make integrations with technologies like CAS less invasive.  In fact the task that has me thinking about this change is basically uPortal integration with a home-grown CAS alternative. Please share your thoughts. drew wills -- Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA. Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source For more information & registration visit: http://www.ja-sig.org/conferences/07summer/index.html --- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]