From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Monday, January 15, 2007
2:08 PM
To: Higgins (Trust Framework)
Project developer discussions
Cc: higgins-dev@xxxxxxxxxxx;
higgins-dev-bounces@xxxxxxxxxxx
Subject: 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
"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>
|
|
|
To
|
<higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
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
>>> 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.
Jim_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
