SAML is certainly part of the solution. JAAS is designed to work within a container. If you have portal apps that are not Java based (like integrating MS Exchange OWA) but you want to use the portal to authenticate access to them then SAML (SiteMinder, NetPoint, Shibboleth, etc...) is your best option. We need jetspeed to support both JAAS and SAML. However, JAAS is fairly limited in its capabilities so you might have to use JAAS just to authenticate to the user and access the database to LDAP/AD to authorization the user. JAAS isn't very good at looking up group/role information about a user.
Speaking of LDAP/AD there are a couple of changes in JS2 that would be nice: 1) Instead of implementing a Jetspeed specific schema we should look at using existing LDAP/AD schemas and map their values (like sAMAccount in Active Directory to username) to internal JS fields. 2) Support for multiple LDAP/AD servers in multiple domains. this is required if you want to have sign-on for internal and external users yet have separate user directories to store their user data. Many commercial and government site require this separation. If we user multiple directories, then JS would need to store a unique value for the users in its database (instead of a username) to properly maintain permissions. For example, if you base the perms on a username and the user is deleted in one directory and someone creates a similarly named user in another directly (though not the same person), then you have just given rights to the wrong person, however if you store something like AD's GUID or the user's email address then the problem is less likely to occur. boyd > -----Original Message----- > From: Mark Fortner [mailto:[EMAIL PROTECTED] > Sent: Monday, December 15, 2003 1:36 PM > To: Jetspeed Users List > Subject: Re: Integration into a Single Sign on Solution > > > I have a similar problem. Unfortunately, SAML isn't the solution. > Does anyone know if there are any > plans to support JAAS in JetSpeed? The J2EE 1.4 spec calls > for JAAS to > be the default authentication mechanism. > This is built into Tomcat 5.0, and there's also some support for it > within the Tomcat 4.1.27 release. > > There should also be some uniform way of handling > Personalisation. The > Preferences API could do > the trick, but I don't see any evidence that JetSpeed is evolving > towards either of these solutions. > > Can anyone confirm the direction that the JetSpeed > development team is > planning on taking with regards to these APIs? > > Regards, > > Mark Fortner > > > On Sunday, December 14, 2003, at 09:42 AM, Frans Thamura wrote: > > > :) SAML support in Jetspeed > > > >> We are looking at Jetspeed as a possible Enterprise Portal > Solution. > >> We > >> have a single sign on solution that we need to integrate into > >> Jetspeed. > >> Basically this solution sits infront of the web application and > >> monitors > >> all traffic. It authenticates against our central user > repository and > >> then > >> sets an encrypted session cookie and sets the username as the > >> Remote_User > >> ENV variable. > >> > >> Has anyone ever done something similar? If so where should I start. > >> Can I > >> have Jetspeed trust the Remote_User variable and if there is an > >> account > >> matching give them their portal setup. If there is no > account it will > >> jump > >> them to the new account page to setup their portal?? > >> > >> Any help would be greatly appreciated. > >> > >> Thanks > >> Jim > > > > Regards, > > > > Frans Thamura <[EMAIL PROTECTED]> > > Intercitra Innovation Center > > +62 855 7888 699 > > > > We help you manage and control. > > > > ---------- > > Tertarik dengan Java Open Source Integration discussion?? > bergabung ke > > JUG Indonesia mailing list, untuk subscribe email aja ke > > [EMAIL PROTECTED] > > > > Website: http://jug-indonesia.dev.java.net > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
