Indeed I have tried to follow your advice, and it's true
StaticPersonAttributesDao is fairly simple to use but it doesn't fit my
requirements. Let me explain. ;)

My current deployment must provide two different scenarios. One of them
gets a X509 client certificate and then it performs a LDAP search in order
to complete attributes. I've successfully managed to configure this
situation. On the other hand, a user can provide a certificate but it turns
out that cannot be found in LDAP. In this case I would like to complete
attribute collection by reading only certificate's fields (name, email,
etc). To explore different options I've tried to write a
credentialsToPrincipalResolver which return the whole X509Certificate (as
base64), and then my new AttributeRepository populates a collection based
on several fields present in the certificate.

So far, it seems to fit in this scenario but I don't know if this approach
mixes concepts or it's absolutely a bad idea. Am I wrong? Is there any
better practice to apply in this case?

Thanks very much for your response.


2012/12/12 Marvin Addison <[email protected]>

> > Now, I'd like to add all the properties of the certificate
> (serialNumber, issuer dn,...) as attributes.
>
> You'd be better served by simply implementing a custom
> CredentialsToPrincipalResolver that does not use PersonDirectory and
> then providing a stub attribute resolver; for example:
>
>   <bean id="attributeRepository"
>     class="edu.vt.middleware.cas.persondir.StaticPersonAttributesDao">
>     <property name="backingMap">
>       <map>
>         <entry key="accountState" value="UNDEFINED" />
>         <entry key="groupMembership" value="UNDEFINED" />
>         <entry key="passwordState" value="UNDEFINED" />
>         <entry key="personType" value="UNDEFINED" />
>         <entry key="uid" value="UNDEFINED" />
>       </map>
>     </property>
>   </bean>
>
> StaticPersonAttributesDao is a very simple class that uses a static
> map for an attribute source. For service registry integration, all you
> need are the same attribute names as those which your
> CredentialsToPrincipalResolver obtains and everything will work fine.
>
> M
>
> --
> You are currently subscribed to [email protected] as:
> [email protected]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to