In CAS 3.5, the actual user attributes won't be stored in the database. Each person is backed by the PersonDirectory and deployers can configure how they want it to work (i.e. no caching, caching, etc.). This will give deployers a lot more flexibility. If it turns out that it works, of course :-)
I should have working code of at least this piece in a few days. Cheers, Scott On Wed, Mar 31, 2010 at 11:06 AM, Jérôme Rautureau <jrautur...@gmail.com>wrote: > I had to truncate my TGT table and it's a (little) issue... > > All my users will have to reauthenticate :). Thanks to the "remember > me" feature, they had forgotten how to do so. > > Here's the data (principal + attributes) witch i'm saving in database > (I had to increase the blob length data in order to save all the > attributes values) > > i have : Active Directory groups, fields like company, > telephonenumber, email, ,... > > ��� sr�4org.jasig.cas.authentication.ImmutableAuthentication67309493 � L� > authenticatedDatet� > Ljava/util/Date;xr�3org.jasig.cas.authentication.AbstractAuthentication_��}��� > � L� > attributest� Ljava/util/Map;L� > principalt�2Lorg/jasig/cas/authentication/principal/Principal;xpsr�%java.util.Collections$UnmodifiableMap��t� > B � L� mq�~� xpsr� java.util.HashMap ��� `� � F� > loadFactorI� threshold...@����� w ��� ��� t� > authenticationMethodt�9org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandlerxsr�6org.jasig.cas.authentication.principal.SimplePrincipal���V�Y}� > � L� > attributesq�~� L� idt� Ljava/lang/String;xpsq�~� sq�~� ?...@����� w ��� > ��� t� Matriculet� 00674t� CheminComplett��Direction générale des > services / Direction générale adjointe / Pôle ressources / Systèmes et > technologies de l'information / RAUTUREAU > Jérômet� Identifiantt� j.rautureaut� > Telephonet� 3425t� Groupessr�&java.util.Collections$UnmodifiableList� %1�� > � L� listt� > Ljava/util/List;xr�,java.util.Collections$UnmodifiableCollection B���^� � > L� ct� Ljava/util/Collection;xpsq�~� sr� java.util.ArrayListx�� ��a� � I� > sizexp��� w ��� t�CCN=g_Projet > - > ICAR,OU=Projets,OU=Groupes,DC=agglo-larochelle,DC=orgt�5CN=tout_le_monde,OU=Listes,DC=agglo-larochelle,DC=orgt�2CN=liste_icar,OU=Listes,DC=agglo-larochelle,DC=orgt�WCN=ICAR > - > CMS_Contrib_DSTI,OU=CMS,OU=Applications,OU=Groupes,DC=agglo-larochelle,DC=orgt�:CN=dga_com,OU=DGA,OU=DGS,OU=CDA,DC=agglo-larochelle,DC=orgt�BCN=gt_phototheque,OU=Groupes > de travail,DC=agglo-larochelle,DC=orgt�LCN=ICAR - > > Developpeurs,OU=Applications,OU=Groupes,DC=agglo-larochelle,DC=orgt�ICN=GED_Utilisateurs,OU=Applications,OU=Groupes,DC=agglo-larochelle,DC=orgt�KCN=SI_Administrateurs,OU=Applications,OU=Groupes,DC=agglo-larochelle,DC=orgt�LCN=GED_Administrateurs,OU=Applications,OU=Groupes,DC=agglo-larochelle,DC=orgt�OCN=ICAR > - > Administrateurs,OU=Applications,OU=Groupes,DC=agglo-larochelle,DC=orgt�,CN=cda_com,OU=CDA,DC=agglo-larochelle,DC=orgt�QCN=DSTI_com,OU=DSTI,OU=Ressources,OU=DGA,OU=DGS,OU=CDA,DC=agglo-larochelle,DC=orgt�OCN=ressources_com,OU=Ressources,OU=DGA,OU=DGS,OU=CDA,DC=agglo-larochelle,DC=orgt�8CN=Admins > du domaine,CN=Users,DC=agglo-larochelle,DC=orgt�KCN=Utilisateurs du > Bureau à distance,CN=Builtin,DC=agglo-larochelle,DC=orgxq�~�!q�~� t� > Prenomt� Jérômet� > compteboiteauxlettrest�%jerome.rautur...@agglo-larochelle.orgt� > DistinguishedNamet�[CN=Jérôme > Rautureau,OU=DSTI,OU=Ressources,OU=DGA,OU=DGS,OU=CDA,DC=agglo-larochelle,DC=orgt� > SiteWebt�1http://intranet/index.php?page=id&uid=j.rautureaut� > NomAffichet� RAUTUREAU Jérômet� NomComplett� Jérôme > Rautureaut� Servicet�*Systèmes et technologies de > l'informationt� emailt�%jerome.rautur...@agglo-larochelle.orgt� Faxt� > 3429t� Emploit� Développeur > systèmest� Societet�+Communauté d'Agglomération de La > Rochellext� j.rautureausr� java.util.Datehj� KYt ��xpw �� '��~�x > > Best regards, > > 2010/3/31 Marvin Addison <marvin.addi...@gmail.com>: > >> The restriction on attributes will have to apply to all storage > mechanisms > >> to ensure a consistent experience (and a consistent API). I'm actually > fine > >> with that. > >> I'll probably enforce a Map<String,List<String>) API > > > > I was thinking it would be possible to keep the Object->String > > conversion an implementation detail internal to the JPA storage layer > > since the other storage mechanisms we support currently don't have > > issues with storing objects. I'll admit it's hard to conceive the > > need to store arbitrary Objects as attributes, so maybe it's just > > simpler to enforce everything be a String to begin with. If anyone > > has a use case for storing non-text attributes in the authentication, > > please speak up. > > > > M > > > > -- > > You are currently subscribed to cas-user@lists.jasig.org as: > jrautur...@gmail.com > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > > > > > -- > Jérôme Rautureau > Développeur Systèmes - CdA La Rochelle > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
