[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Two proposed IdAS changes

Speaking about IdAS, what is the schedule to get this back on a 1.4 JVM ?

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "Jim Sermersheim" <jimse@xxxxxxxxxx>"Jim Sermersheim" <jimse@xxxxxxxxxx>

          "Jim Sermersheim" <jimse@xxxxxxxxxx>
          Sent by: higgins-dev-bounces@xxxxxxxxxxx

          01/12/2007 06:10 PM

          Please respond to
          "Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>





Re: [higgins-dev] Two proposed IdAS changes

More than an entire day passed before we found issues with these new interfaces -- yay!

However, what we found today is that rather than having the root interface be IAuthNPropertiesMaterials (which is comprised of a list of properties), it should have been something like IAuthNFilterMaterials which is comprised of an IFilter. In a way, these two concepts are the very similar. IAuthNPropertiesMaterials could be said to be comprised of a filter where the filter is the AND of all listed properties. At the end, I'll give the use case that drove us here.

New thinking is to do this:
public interface org.eclipse.higgins.idas.IAuthNFilterMaterials (has an IFilter)
public class org.eclipse.higgins.idas.impl.AuthNFilterMaterials implements IAuthNFilterMaterials
public class org.eclipse.higgins.idas.impl.AuthNNamePasswordMaterials extends AuthNFilterMaterials
public class org.eclipse.higgins.idas.impl.AuthNSelfIssuedMaterials extends AuthNFilterMaterials
public class org.eclipse.higgins.idas.impl.AuthNAnonymousMaterials extends AuthNFilterMaterials

public class org.eclipse.higgins.idas.impl.AuthNLeastPrivilegedUserMaterials extends AuthNFilterMaterials

To retain the convenience we had with IAuthNPropertiesMaterials, AuthNFilterMaterials can still allow a list of properties to be passed in and will interpret this as a filter of ANDed filter items.

Use case:

We started thinking about how the upcoming mapping CP would deal with one of these things when it found property names in the list that needed to be mapped out to multiple different properties. For example, say the property name for "...#uniqueID" maps to "name" or "username". The mapping CP needs to change the AuthN materials prior to forwarding them to the underlying CP. Somehow, the mapping CP needs to indicate that the newly mapped "name" and "username" assertions are to be ORed when the underlying CP is performing its evaluations. With a simple list of properties, There was no way to represent "OR". Using a filter preserves the usefulness of the list while allowing more complex identity assertions to be conveyed.


>>> Jim Sermersheim<jimse@xxxxxxxxxx> 1/10/07 5:23 PM >>>
The changes discussed in this thread have just been committed, so all IdAS CP's will need to update in order to work with the latest IdAS. Any IdAS consumer calling IContext.open(AuthNNamePasswordMaterials) needs to import that from the impl package.

The LDAP CP has been rebuilt and seems to be ok.

higgins-dev mailing list

GIF image

GIF image

GIF image