Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Making progress on higgins.eclipse.org

Will the mapping support be able to allow code fragments to be executed during the retrieval of data so that various transforms can be performed ?
 
Jeffrey C. Broberg
CA
Senior Architect, Development
Tel: +1-508-628-8490
Jeffrey.Broberg@xxxxxx
 


From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Tuesday, January 09, 2007 8:22 PM
To: Higgins (Trust Framework) Project developer discussions
Subject: Re: [higgins-dev] Making progress on higgins.eclipse.org

Duane Buss is implementing a mapping context provider.  The intent is that one will be able to plug this provider in front of an endpoint context provider (like the LDAP CP) so different kinds of mappings can happen way in and out.  The benefit of putting the code into a CP and stacking them like this is that it can be used in front of any other CP.

Jim


Broberg, Jeffrey C wrote:
jim - who is working on the claim-attribute mapping support ?
 
jeff
 


From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Tuesday, January 09, 2007 1:19 PM
To: Higgins (Trust Framework) Project developer discussions
Subject: Re: [higgins-dev] Making progress on higgins.eclipse.org

Just a couple technical nits with the message below: It should read like this:
The java.naming.security.authentication values for the sun JNDI LDAP provider we're using are documented here: http://java.sun.com/products/jndi/tutorial/ldap/security/auth.html.  BTW, if you would like us to install an eDirectory LDAP server on an eclipse server, we'd be happy to set one up for you.  However, we really don't have any experiences with the intricacies of setting up and configuring other LDAP servers ice providers.

Tom Doman wrote:
Mike,

The java.naming.security.authentication values for the sun JNDI provider we're using are documented here: http://java.sun.com/products/jndi/tutorial/ldap/security/auth.html.  BTW, if you would like us to install an eDirectory LDAP server on an eclipse server, we'd be happy to set one up for you.  However, we really don't have any experiences with the intricacies of setting up and configuring other LDAP service providers.

Tom

  
Michael McIntosh <mikemci@xxxxxxxxxx> 1/9/2007 10:47 AM >>>
        
higgins-dev-bounces@xxxxxxxxxxx wrote on 01/09/2007 11:29:41 AM:

  
Mike,

We hard coded some tables into the LDAP CP to handle mapping of 
claim URI's in and out of the CP.  However, those attribute 
definitions are not required by the CP to exist in the schema of the
backing LDAP store.  If the IdAS consumer asks for "http://schemas.
xmlsoap.org/ws/2005/05/identity/claims/emailaddress" the map 
dictates that the LDAP CP ask for several possibilities ("mail", "e-
mail", "emailaddress", "rfc822mail", etc.) any of which, if they do 
not exist, will not be a problem.  No results will be returned.  As 
I said earlier, this hard coded table will be removed from the LDAP 
CP when our mapping CP is implemented.  Then, this kind of mapping 
specification will be done in the mapping CP configuration file.  At
any rate, the upshot is, the CP still doesn't require any schema, 
our reference application does.  I'll check on the exact LDAP 
classes and attributes being used by it and send you those under 
separate cover.

The values for java.naming.security.authentication and java.naming.
ldap.attributes.binary are a couple of many environment variables 
which can be specified to control the behavior of some of the JNDI 
API calls.  Specifically, java.naming.security.authentication in 
this case specifies that we're doing simple user name\password 
authentication.  The java.naming.ldap.attributes.binary variable 
    
What other values/authentication methods are possible/supported?

  
specifies that the "GUID" attribute is to be returned in binary 
format rather than base64Binary (I think that's the default format).

Tom

    
Michael McIntosh <mikemci@xxxxxxxxxx> 1/8/2007 12:44 PM >>>
          
higgins-dev-bounces@xxxxxxxxxxx wrote on 01/08/2007 01:48:55 PM:

    
Mike,

The LDAP CP does not require any particular set of schema to be 
present.  Applications may, but the CP itself does not.  The 
      
I guess I am confused. If no specific schema is required, how does the 
    
CP 
  
decide which attributeValue from LDAP should be used when it is asked 
    
for 
  
one of the Claim URIs?

    
required CP configuration isn't too bad, I'll include the config we 
used on the WAG server for the IIW demo here:

<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">
        <bci:realm 
        connectorType="org.bandit.ia.connectors.
LDAPConnectorInitialCtxFactory" 
        desc="Corporate LDAP Directory"
        id="Corporate-LDAP-Server">
                <bci:connection xsi:type="bci:LDAPConnector">
<bci:address>ldap://localhost:389</bci:address>
                        <bci:dsnameprefix>cn=</bci:dsnameprefix>
                        <bci:dsnamepostfix>,ou=people,dc=wag,
dc=bandit-project,dc=org</bci:dsnamepostfix>
                </bci:connection>
                <bci:env prop="java.naming.security.authentication" 
value="simple" />
                <bci:env prop="java.naming.ldap.attributes.binary" 
value="GUID" />
        </bci:realm>
</bci:realms>

Note that the name prefix configuration is what allowed us to pass 
simple names thru IdAS to the LDAP CP like "tdoman".  This will go 
away when we finish our mapping CP implementation.
      
Can you say more about allowed values for 
java.naming.security.authentication and 
java.naming.ldap.attributes.binary?

    
As for the LDAP store itself and what data is there, what would you 
like to do?  Here are a few choices:
1. Point your LDAP CP configuration at the LDAP directory running on
ldap://wag.bandit-project.org or ldaps://wag.bandit-project.org.
2. Use the Novell created LDAP utility we've used to unit test our 
LDAP CP while it was developed in the bandit project.  It's backed 
by an XML file with it's own format.
3. Install, configure, and populate an LDAP server\store of your own.
      
I am leaning towards #3 since I'd like the install to be as self 
    
contained 
  
as possible (and the Eclipse Firewall rules are brutal).
I tried #2, but it seems to require X Windows on Linux and that machine 
does not have it installed.

    
Thanks,
Tom

      
Michael McIntosh <mikemci@xxxxxxxxxx> 1/7/2007 9:22 AM >>>
            
Tom,

I am not very directory server savvy - can you send me whatever schema 
      
  
files and other configuration details I'd need to have a directory 
      
work 
  
with your LDAP CP?

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 01/02/2007 01:19:08 PM:

      
Mike,

You shouldn't need anything more than what we've already setup on 
the demo machines with the exception of an LDAP server of your 
choice.  The LDAP CP configuration file would only need to be 
modified to point at that source.  Of course, it'd be up to you to 
make sure that the data you want is loaded there as well.  Anyway, 
what else do you need help with?

Tom

        
Michael McIntosh <mikemci@xxxxxxxxxx> 12/21/06 1:32 PM >>>
              
Thanks to Valery, I've made some progress on configuring 
higgins.eclipse.org.
I need to get the LDAP CP configured on this machine.
Can someone from Novell help me to understand what needs to be 
        
installed 
    
and configured on this machine?

thanks,
Mike
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev 
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev 
        
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev 
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev 
      
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev 
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev 
    
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
  


_______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev


Back to the top