Please take me off your mailing list.
<br><br><br>>From: "Paul ANDERSON"
<[EMAIL PROTECTED]><br>>Reply-To: "Jetspeed
Users List" <[email protected]><br>>To:
"Jetspeed Users List"
<[email protected]><br>>Subject: RE: Provisioning
users from outside Jetspeed 2, security services<br>>Date: Wed, 29 Jun
2005 17:28:03 +0100<br>><br>>My question was:<br>>Assuming a custom
LDAP implementation that works as Florian describes, or the standard
Jetspeed one that uses its own schema and can't be mapped to an existing
one:<br>>Can you add/remove users to LDAP via other applications? Or do
you hit problems with admin portlet markup caching, store caching, variable
caching, etc? I.e. does Jetspeed assume all persistent updates have to be
applied through its own toolset?<br>><br>>And does everything
including preferences have to be either in LDAP or an RDBMS? Or can you mix
them - LDAP for authn, authz roles and SQL for low-level ACLs and
portlet-related data?<br>><br>>Paul<br>><br>>-----Message
d'origine-----<br>>De : Randy Watler
[mailto:[EMAIL PROTECTED]<br>>Envoyé : 29 June 2005 17:16<br>>À :
Jetspeed Users List<br>>Objet : Re: AW: Provisioning users from outside
Jetspeed 2, security services<br>><br>>Florian,<br>><br>>Please
review the archives for this and the dev list.<br>><br>>There are two
techniques:<br>><br>>- implement UserManager and/or other security SPI
components for J2, or<br>>- implement a custom
SecurityValve.<br>><br>>You will find both techniques discussed in the
archives.<br>><br>>Randy<br>><br>>Florian Theurich
wrote:<br>><br>> >Hi,<br>> ><br>> >I suppose I have a
similar issued to solve like Paul...<br>> ><br>> >Using
Jetspeed2 our users log in the windows domain and are automatically<br>>
>authenticated against our portal as they are users in the corporate
Active<br>> >Directory. An Active Directory group further tells us
which business unit he<br>> >works for and which role he obtains
(editor, editor in charge, contact admin<br>> >etc.)...<br>>
><br>> >But where can we tell Jetspeed to actually grab or 'inject'
the role (as<br>> >Jetspeed seems to dot it when your users and their
roles are stored in the<br>> >DB) so that Jetspeed can use it for
applying profiling rules and eventually<br>> >come up with the pages
that are to display for a particular user? So in a<br>> >nutshell how
can we tell J2 to make use of the role and group that we<br>> >receive
from the Active Directory...?<br>> ><br>> >I hope I made myself
clear...<br>> >Any suggestions are highly appreciated<br>>
>Cheers<br>> ><br>> >Florian<br>> ><br>>
><br>> ><br>> >-----Ursprüngliche Nachricht-----<br>>
>Von: Paul ANDERSON [mailto:[EMAIL PROTECTED]<br>>
>Gesendet: Dienstag, 28. Juni 2005 18:44<br>> >An: Jetspeed Users
List<br>> >Betreff: Provisioning users from outside Jetspeed 2,
security services<br>> ><br>> >Can I create/remove users
directly in the RDBMS/LDAP backend for<br>> >Jetspeed 2, or does it
assume that changes will go through the admin<br>> >portlets and
engine?<br>> ><br>> ><br>> ><br>> >Can user profile
fields be changed outside, or are they cached either as<br>> >fields
or markup in the admin portlets?<br>> ><br>> ><br>>
><br>> >Can I store authentication info, role info, ACL info,
preferences and<br>> >working data all in different backends depending
on the security<br>> >services implementation, or is there some reason
why they have to be in<br>> >the same store?<br>> ><br>>
><br>> ><br>> >Has anyone successfully tried a setup where
Jetspeed just provides<br>> >services for existing users who are
administered somewhere else?<br>> ><br>> ><br>> ><br>>
>Thanks,<br>> ><br>> ><br>> ><br>> >Paul.<br>>
><br>> ><br>> ><br>> ><br>> ><br>>
><br>>
>---------------------------------------------------------------------<br>>
>To unsubscribe, e-mail:
[EMAIL PROTECTED]<br>> >For additional
commands, e-mail: [EMAIL PROTECTED]<br>> ><br>>
><br>> ><br>> ><br>>
><br>><br>><br>><br>>---------------------------------------------------------------------<br>>To
unsubscribe, e-mail: [EMAIL PROTECTED]<br>>For
additional commands, e-mail:
[EMAIL PROTECTED]<br>><br>><br>>---------------------------------------------------------------------<br>>To
unsubscribe, e-mail: [EMAIL PROTECTED]<br>>For
additional commands, e-mail:
[EMAIL PROTECTED]<br>><br>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
