Shibboleth Developers

[Peter Williams <>]

In the windows server world (a commodity OS, for mere mortals who make up the 
masses), folks tend to use ldap/active-directory for metadata management, 
distribution and aggregation (at multiple distribution points). The infamous  
case is group policy, in which stored objects (signed objects rather like 
signed shib xml  metadata files) are stored in a [replicated] ldap container. 
Those administration points in the directory name space that wish to apply 
the policy stated therein  link/refer to the contained object or its replica 
(for admin point, read SP entityname). This produces a tightly controlled 
policy enforcement apparatus - one that fits your typically multi-site LAN 
with a 1000+ workstations to manage,. or 10,000 users whose feature sets 
should be profiled by groupings. The AD multi-mastering and replication 
support facilitates multi-site deployments, and thus the management of large 
peer-peer metadata networks.

If this "enterprise MAN" approach is a too tightly coupled example of 
directory based policy management, there are other examples of the directory 
being used to manage distributed systems. In the world of patch updates 
(using the system center configuration application of AD), schema updates to 
AD allows mobile clients to talk to the management web service in their 
homesite to learn the alternative management point in the local site  - which 
locates the [local] distribution points providing compressed streams of patch 
data. patches are signed, so trust in availability is managed orthogonally to 
trust for integrity. The distribution architecture plus the orthogonality 
property produces a  loosely-controlled policy enforcement apparatus - one 
that fits virtualization fabrics supproting virtual data centers built out of 
vmware or azure clouds, either on-premise or public, and is intended to scale 
to folks with 100,000-1,000,000 pdas to manage [indirectly].

In our SSO world (that cooperates today with about 3 Shib2 2.0 SPs, and 1 
Shib2 2.2 IDP), we have finally got critical mass with the ADFSv2 
architecture, particularly as it cooperates with the Ping Federate SAML 
server's [auto-connect] methods for handling large amounts of dynamic 
metadata exchange (in large peer/peer federations). As all our ADFS and 
PingFederate SAML server instances of SAML endpoints can expose ldap/ldaps 
endpoints , this avails us of the failover, discovery, knowledge management 
and linking methods hinted at above. if I contrast that feature set with the 
features outlined in the I-D, im not sure what http/https brings to the table 
(when combined with yet another query-based method for metadata retrieval) - 
that ldap queries in URLs (once expressed over SSL) do not already bring.

since Shib folks are already building and supporting ldaps attribute 
resolvers (with app-controlled failover polices, rather than the policies 
built into JNDI), why not repurpose those very same techniques for metadata 
location/retrieval stored in other ldap attributes? The policy management 
architecture does to have to be as advanced as the examples I gave from group 
policy or system center; but might at least share benefit from the existing 
work done on leveraging (peer/peer) ldap services when supporting highly 
scalable , highly fault tolerant internet-cnetric location/discovery/access 
of metadata about endpoints.
________________________________________
From: 

 
[]
 On Behalf Of Chad La Joie 
[]
Sent: Wednesday, September 15, 2010 12:20 PM
To: 

Subject: Re: [Shib-Dev] More info about java-metadata-aggregator project

There is no documentation for it yet other than an IETF document[1] I
wrote up describing the front-end of the system.

The basic goal of the project is to help with the technical
infrastructure needed for inter-federation.  It attempts to answer the
question "how do I read in all these metadata documents, verify them,
 mungethem, and spit them back out again as something useful to a
different group".

It is not, I would say, something the average IdP/SP deployer would
run.  It's much more likely to be run by organizations that facilitate
the interactions of many IdPs and SPs, like a federation.

The code is also not yet ready for public consumption, it's still
being worked on.  Some APIs are still changing, etc.  If you want to
follow along you can find docs pulling in opensaml3 here:
https://spaces.internet2.edu/display/~/Shib3Helios

[1] http://tools.ietf.org/html/draft-lajoie-md-query-00

On Wed, Sep 15, 2010 at 15:07, Yang, Jack 
<>
 wrote:
>
>
> Chad,
>
>                 I have following questions about “java-metadata-aggregator”
> project:
>
>
>
> 1). What is the project for?
>
> 2). Any more reading materials related to the project?
>
>
>
> 3). I download the source, but maven (pom.xml) has a dependency on:
> opensaml-util 3.0.0-SNAPSHOT, can you tell me where can I get the source for
> this opensaml-util 3.0.0-x?
>
>
>
>                 Thanks.
>
> Best Regards!
>
> Jack Yang
>
>
>
> The information contained in this email message and its attachments is
> intended only for the private and confidential use of the recipient(s) named
> above, unless the sender expressly agrees otherwise. Transmission of email
> over the Internet is not a secure communications medium. If you are
> requesting or have requested the transmittal of personal data, as defined in
> applicable privacy laws by means of email or in an attachment to email, you
> must select a more secure alternate means of transmittal that supports your
> obligations to protect such personal data. If the reader of this message is
> not the intended recipient and/or you have received this email in error, you
> must take no action based on the information in this email and you are
> hereby notified that any dissemination, misuse or copying or disclosure of
> this communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by email and delete the
> original message.



--
Chad La Joie
www.itumi.biz
trusted identities, delivered