[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Mapping at what level?
|
Marc,
Okay, cool, thanks for the clarifications. I think we're pretty much
in agreement actually and I appreciate the expertise you're bringing
to this topic.
On the attribute mapping config, right, that's what I was trying,
not too cleverly to say. That is, to me, it would be in the CP
configuration file regardless of how it was represented. For what
I'm proposing, it would be a piece of JavaScript in the configuration
file which would check a configured mapping table (probably a lot
like your "ldap:cn" example) and use a default if there was no map
in the table.
Here's an explicit example:
The LDAP attribute is "objectClass". The JavaScript does the
following ... If there's no map in the table, use the default
mapping rule which is to prepend:
http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_
onto it. The OWL ontology emitted from getSchema() would use
the same JavaScript PDP and thus name it the same way and
then would properly derive it from the base Higgins ontology as
it does today.
Actually, there are some examples of what I'm talking about
checked into the org.eclipse.higgins.idas.cp.jspolicy.test project
in the JSPolicyJNDICPTest.xml file ... I've attached it here.
Anyway, I'm proposing to use the JavaScript toolkit code Duane
wrote for the first kind of mapping within the JNDI CP and that,
yes, we use the JavaScript Policy CP for the second kind.
Does that cause heartburn for anyone?
Tom
>>> "Marc Boorshtein" <mboorshtein@xxxxxxxxx> 3/13/2007 1:18 PM >>>
>Having a CP be "ignorant" of anything beyond what the remote source
gives it is basically option #1. However, I believe that the basic
tenet of IdAS is that the CPs are supposed to present a consistent
face to the IdAS user and what I was implying earlier was that option
#1, I believe, violates that tenet. That is, the CP MUST do SOME
mapping. So, maybe that's option #5.
Well, just to clarify I think that the IdAS should have a standard as
how to name attributes. For instance most virtual directories manage
this by standardizing on LDAP concepts (entries, multi value
attributes and DN based names). The CP should be responsible for
mapping to this standard. In addition to mapping to the IdAS standard
data representations there may also be application specific mappings.
My example of mapping cn from givenName and sn is such an example.
These types of application mappings should be specific to a deployment
and shouldn't be the responsibility of a CP.
> With respect to name mapping, this is, in fact, what we've already done in the JNDI CP to date. There are two configuration elements which define what to tack on to the front (say, "cn=") and what to tack onto the back (say, ",ou=people,dc=wag,dc=bandit-project,dc=org") of the subjectID passed in.
>
Again to clarify. The JNDI CP assumes that the username is the RDN of
an LDAP DN. What if (as is the case with AD) that the rdn is not a
username? AD uses the cn as the rdn attribute while samaccountname is
used for the username. In this scenario a mapping cp would need to
get the CN attribute based on the value of the samaccountname
attribute supplied by the user. (I currently disagree with this
design, but thats another discussion). So the point of my original
analogy is that the CP is "ignorent" to a degree of the application
while performing the needed mapping for the common IdAS
infrastructure.
> With respect to attribute mapping, we could do the exact same kind of inflexible configuration elements. They'd say "here's what you tack on the front of the LDAP schema to make it look like a Higgins OWL type".
>
Not sure I follow. My thought would be more like a config file (or
maybe part of the CP cfg?) that says ldap:cn=idas:http://..... this
can be utilized as a tool for simple mappings and the author of the CP
is responsible for anything more complex.
The main point I am trying to make is that there are two uses of the
word "mapping" here. The first is the mapping from the local resource
to the IdAS and the second is the mapping of an applications needs to
what data stores may provide. The first is perfectly acceptable (and
should be expected) to be required by any CP. The second is where I
see a JS based CP most useful.
Marc
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
<bci:realms xmlns:bci="http://www.bandit-project.org/commonidentity";
xmlns:xacml="urn:oasis:names:tc:xacml:2.0:policy:schema:os"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<SCRIPT LANGUAGE="javascript"> <![CDATA[
var multimap = {
presented: [],
real: []
};
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname";] =
["givenname", "2.5.4.42"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname";] =
["sn", "surname", "2.5.4.4"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress";] =
["mail", "email", "emailaddress", "internetaddress",
"1.2.840.113549.1.9.1", "rfc822mailbox", "0.9.2342.19200300.100.1.3"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress";] =
["street", "streetaddress", "2.5.4.9"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality";] =
["localityName", "2.5.4.7"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince";] =
["st", "stateprovincename", "2.5.4.8"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode";] =
["postalcode", "2.5.4.17"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country";] =
["cn", "countryname", "2.5.4.6"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone";] =
["homephone", "telephonenumber", "2.5.4.20"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone";] =
["otherphone"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone";] =
["mobilephone"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth";] =
["dateofbirth"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender";] =
["gender"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier";] =
["guid", "privatepersonalidentifier"];
multimap.presented["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/groupmembership";] =
["groupmembership"];
for (elem in multimap.presented)
{
// out.println("elem " + elem);
// out.println("multimap.presented[elem] " + multimap.presented[elem]);
for (real in multimap.presented[elem])
{
// out.println("real " + multimap.presented[elem][real]);
multimap.real[multimap.presented[elem][real]] = elem;
// out.println("multimap.real[multimap.presented[elem][real]] " + multimap.real[multimap.presented[elem][real]]);
}
// for (elem in multimap.real)
// out.println("multimap.real " + elem + " : " + multimap.real[elem]);
}
]]>
</SCRIPT>
<bci:realm desc="JNDI Mapping Realm" id="Corporate-LDAP-Server-Mapper"
connectorType="org:bandit:higgins:cp:idas:jspolicy">
<JSPolicyAction id="presentedOpenContextRefToReal" evalType="javascript"> <![CDATA[
importPackage(java.io);
configFile = new java.io.File("JNDICPTest.xml");
new java.net.URI(configFile.toURI().toString() + "?id=Corporate-LDAP-Server");
]]>
</JSPolicyAction>
<JSPolicyAction id="presentedTypeToReal" evalType="javascript"> <![CDATA[
map = multimap.presented[String(PARAM.toString())];
if (!map)
{
var re = new RegExp("^http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_";, "i");
RESULT = String(PARAM.toString()).replace(re, "");
}
RESULT = map;
]]>
</JSPolicyAction>
<JSPolicyAction id="realTypeToPresented" evalType="javascript"> <![CDATA[
map = multimap.real[String(PARAM.toString())];
if (!map)
map = "http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#attr_"; + PARAM.toString();
RESULT = map;
]]>
</JSPolicyAction>
<JSPolicyAction id="presentedDSTypeToReal" evalType="javascript">
<SCRIPT LANGUAGE="javascript"> <![CDATA[
var re = new RegExp("^http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#class_";, "i");
RESULT = String(PARAM.toString()).replace(re, "");
]]>
</SCRIPT>
</JSPolicyAction>
<JSPolicyAction id="realDSTypeToPresented" evalType="javascript">
<SCRIPT LANGUAGE="javascript"> <![CDATA[
RESULT = "http://www.eclipse.org/higgins/ontologies/2006/higgins/ldap#class_"+String(PARAM.toString());
]]>
</SCRIPT>
</JSPolicyAction>
<JSPolicyAction id="presentedCuidToReal" evalType="javascript"> <![CDATA[
RESULT = "cn=" + PARAM + ",ou=people,dc=wag,dc=bandit-project,dc=org"
]]>
</JSPolicyAction>
<JSPolicyAction id="realCuidToPresented" evalType="javascript">
<SCRIPT LANGUAGE="javascript"> <![CDATA[
var re = new RegExp("^cn=(.*),ou=people,dc=wag,dc=bandit-project,dc=org$", "i");
RESULT = String(PARAM.toString()).replace(re, "$1");
]]>
</SCRIPT>
</JSPolicyAction>
<JSPolicyAction id="presentedValueToReal" evalType="javascript"> <![CDATA[
importPackage(Packages.org.eclipse.higgins.idas);
var re = new RegExp("^js", "g");
if (presentedType == "CUIDSyntax") {
RESULT = PARAM.getValue().replace(re, "vc");
}
else {
RESULT = PARAM;
}
]]>
</JSPolicyAction>
<JSPolicyAction id="realValueToPresented" evalType="javascript"> <![CDATA[
importPackage(Packages.org.eclipse.higgins.idas);
importPackage(Packages.org.eclipse.higgins.idas.impl);
importPackage(Packages.org.bandit.higgins.cp.jspolicy);
var re = new RegExp("^vc", "g");
if (presentedType == "CUIDSyntax") {
//TODO how do we detect java types for the correct casts?
RESULT = new Packages.org.eclipse.higgins.idas.impl.BasicValueString(
String(PARAM.getData()).replace(re, "js"));
}
else {
RESULT = PARAM;
}
]]>
</JSPolicyAction>
</bci:realm>
</bci:realms>
