What are the minimum requirements for a custom login?

[Rob Bradley <ro...@visionsolutions.com>]

I am currently trying to replace the login portlet with an authentication
against our AS/400 server.

Our requirements are very minimal:

1> User and password validate against AS/400 profile, not Jetspeed database.
2> Two access levels: Public view only, Admin create pages and add or remove
portlets.

I know how to authenticate against an AS/400 so have no problems there but
would like to know the minimum requirements to override the actual
authentication piece within Jetspeed. We're happy to keep all other features
such as the login portlet and roles as standard. We do not need users to be
able to manage "profiles" or anything like that.

Many thanks in advance for your help.

Rob Bradley
-- 
View this message in context: http://www.nabble.com/What-are-the-minimum-requirements-for-a-custom-login--tp24056266p24056266.html
Sent from the Jetspeed - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org

Re: What are the minimum requirements for a custom login?

[David Sean Taylor <d....@onehippo.com>]

On Jun 16, 2009, at 8:03 AM, Rob Bradley wrote:

>
> I am currently trying to replace the login portlet with an  
> authentication
> against our AS/400 server.
>
> Our requirements are very minimal:
>
> 1> User and password validate against AS/400 profile, not Jetspeed  
> database.
> 2> Two access levels: Public view only, Admin create pages and add  
> or remove
> portlets.
>
> I know how to authenticate against an AS/400 so have no problems  
> there but
> would like to know the minimum requirements to override the actual
> authentication piece within Jetspeed. We're happy to keep all other  
> features
> such as the login portlet and roles as standard. We do not need  
> users to be
> able to manage "profiles" or anything like that.
>
> Many thanks in advance for your help.
>

(I have gathered and included previous responses to these questions  
including my own)

If I understand your question, you want to store your users outside of
Jetspeed and then still use the Jetspeed login page?

Basically you have two choices then:

1. implement the Jetspeed security services at the Jetspeed API level
for a tight integration. This allows you to use Jetspeed
administrative portlets all out of the box. Downside is you have to
write the Java code to implement the security interfaces

2. Write a custom authentication solution which might involve SSO (as
shown below) and combine that with a filter to
populate the required Jetspeed Subject in the request

One thing Im not sure of is how you will authenticate against the AS/ 
400, with a Java call, or with some tokens provided by a filter such  
as Shibboleth or NTLM

For the second approach take a look at the PortalFilter.java (you will  
need to check out the source)
Recommend extending the PortalFilter class to identify your SSO system  
provided userid
(cookies/headers/parameters/attributes etc.). If the user is known  
within the Jetspeed security system, use the UserManager
to instantiate a User object and retrieve its Subject  
(User.getSubject()) - if the user is unknown, you can create your own  
Subject and provide it with a
UserSubjectPrincipalImpl for the userid and any other (Jetspeed)  
RolePricipalImpl or GroupPrincipalImpl instances
you'd need - store the Subject in the session (not the request as Æde  
said):  
session.setAttribute(PortalReservedParameters.SESSION_KEY_SUBJECT,
subject); - wrap the current request with a PortalRequestWrapper -  
proceed with the filterchain

There a similar examples for authentication with NTLM:
http://portals.apache.org/jetspeed-2/deployguide/guide-ntlm.html

or more recently, Shibboleth:

http://portals.apache.org/jetspeed-2/deployguide/config-sso.html

also see the section titled "Integrating with External SSO" on the  
config-sso.html

Take a look at the source for PortalFilter.java,  
ShibbolethPortalFilter.java

So you will need to consider things like:

* will we use the self-registration and forgotten password?
* will we need to administer users with Jetspeed?
* will we need to administer roles and groups and associate them with  
users?

If your answer is no to all of the above, its best to just take  
approach #2


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org