Re: Requirements Gathering for Liberty ID-WSFToolkit

Fantastic feedback, John!

We will definitely target Tomcat as a deployment platform as well as the
others mentioned -- we develop internally on Tomcat (or JBoss+Tomcat)
and have always considered it our base/reference Servlet platform.

Your points about the security token being widely consumable -- at this
point we are targeting a Java-only version of this toolkit. However,
conceivably you could write adapters (in Java) which take the security
tokens and extract the useful elements (or leave them as XML) and hand
them off to other systems such as you describe. ("VisualFoxPro"?)

The schemas you refer to, all exist in various published forms. The ID-
FF schemas in particular contain the messages you thought were missing. 

Try this link:

http://projectliberty.org/specs/liberty-idff-protocols-schema-1.2-
errata-v2.0.xsd

Other notes... We didn't mean to imply that we were combining Discovery,
Interaction, and Employee Profile into one "chunk" of code. Instead, I
meant to say, that the first version of the toolkit will, at a minimum,
cover those areas. But they will be loosely coupled -- you will be able
to use just the Discovery portion of the toolkit, for example, to create
Discovery queries or publish services, whether or not you also use the
other parts of the toolkit.

Not going to address all your other points but they were extremely
helpful and are well in-line with where we intend to take this toolkit.

Thanks and regards,

Bryan Field-Elliot
Ping Identity Corporation





On Mon, 2005-01-24 at 11:53 -0500, John Lorenti wrote:

> Bryan,
> I'm really glad that Ping Identity is pursuing this, since this is 
> exactly what addresses our present need!  I've been in the process of 
> constructing a set of WSF services to handle Authentication, Personal 
> Profile, and Preferences for all of our disparate (particularly non 
> browser based) systems.  I really haven't gotten much beyond roughing 
> them out, but there are some aspects that have come to my attention 
> during the process, like:
> 
> The format and exchange of the Security Token accessible to all client 
> types (like those in the Liberty Client Profiles Specification).  In 
> our case, it needs to be consumable by a variety of clients (like Java, 
> VisualFoxPro, Access, ColdFusion) and will also be used for session 
> management.
> 
> The schemas being used to define Authentication and Personal Profile 
> document messages.  I see where Query, QueryResponse, Modify and 
> ModifyResponse are referenced, but their definitions don't appear to be 
> in the ID-SIS-PP schema.  It's a similar case for 
> RegisterNameIdentifierRequest/Response, FederationTermination, 
> LogoutRequest, and the other Authn operation documents.  (Granted, the 
> Libety Specs I'm looking at are from October, so I may be missing or 
> have missed something.)  If these schemas don't already exist, how will 
> these messages be addressed in a standard way?
> 
> 
> Regarding the items you mentioned, the following comes to mind:
> 
> I can understand your wanting to combine the Discovery, Employee 
> Profile and Interaction services rather than always first obtaining and 
> passing around the Discovery Service's authentication assertion.  But 
> if including the Employee Profile, then it seems to me that it would be 
> beneficial to also include the Liberty ID-SIS Personal Profile Service 
> in this conglomeration.  However, are two orthogonal issues being 
> combined here?  Would it be better to keep Discovery/Interaction 
> separate from the Employee/Personal profiles, since the former deals 
> with process and the latter with data?
> 
> I'd like to propose adding Tomcat to Shawn McKinney's list of 
> application containers to be supported.
> 
> I'd like to see SOAP Endpoints explicitly provided (and extendable).
> 
> I'd like to have ID-WSF and ID-FF efficiently coexist side by side, 
> able to use the same repositories and custom processes for 
> authentication (without duplication of either).
> 
> The "granularity" question is tough to describe.  I'd like complete 
> flexibility to keep identity data any way I'd like, but I wouldn't want 
> to have to write a class for each data column.  However, writing a 
> single class - that conforms to a toolkit interface - for each service 
> area (ie: one for authentication, another for personal profile, etc.) 
> would be completely reasonable.  Similarly, interfaces defining how to 
> obtain Profile data (shielding the developer from processing XPath 
> queries directly) would be very welcome.  Even if it had to be one 
> interface/subclassed Adapter per Profile subsection - like one each for 
> InformalName/CommonName/LegalIdentity, EmploymentIdentity, AddressCard, 
> MsgContact, Facade, Demographics, etc.
> 
> Any aids provided to facilitate request consumption and response 
> generation will be greatly appreciated!
> 
> I don't know how much of this is what you were looking for, but this is 
> what comes to mind thus far.    As I get into this more, may I send 
> additional thoughts on the subject?
> 
> If you'd like, please feel free to contact me about any of this.
> Sincerely,
> -John
> 
> 
> John R. Lorenti, MS
> Software Architect
> Virginia Department of Criminal Justice Services
> 805 East Broad Street; Tenth Floor
> Richmond, VA 23219
> (804) 640-6066
> [email protected]
> 
> On Jan 20, 2005, at 11:58 AM, Bryan Field-Elliot wrote:
> 
> >  Hello SourceID list members!
> >
> >  Ping Identity is now developing a Java-based toolkit to aid in the 
> > construction of Liberty ID-WSF (Identity Web Services Framework) 
> > applications. We are targeting a Q1 release, in beta form. At a 
> > minimum, this first version of the Liberty ID-WSF toolkit will have 
> > the following characteristics:
> >
> >  - Java-based
> >  - Aid in the construction of requests, transmission of requests, 
> > reception of requests, and creation of responses for Liberty ID-WSF 
> > messages
> >  - Coverage of the Discovery protocol, the Employee Profile Service, 
> > and the Interaction Service.
> >  - Aid in the construction of applications based upon the DST (Data 
> > Services Template)
> >  - Aid in the handling of various Liberty Security Mechanisms.
> >
> >  At this time we'd like to solicit feedback from the list on what 
> > other architectural considerations you would like for us have, as we 
> > continue to evolve the toolkit.  e.g.:
> >
> >  - With what kind of environments would you like to be able to easily 
> > integrate the toolkit?
> >  - How granular would you like the toolkit primitives to be?
> >
> >  Comments or ideas would be appreciated!
> >
> >  Thank you,
> >
> >  Bryan Field-Elliot
> >  Ping Identity Corporation
> >
> >
> >  _______________________________________________
> > sso-users mailing list
> > [email protected]
> > http://lists.sourceid.org/mailman/listinfo/sso-users
> 
> _______________________________________________
> sso-users mailing list
> [email protected]
> http://lists.sourceid.org/mailman/listinfo/sso-users

_______________________________________________
sso-users mailing list
[email protected]
http://lists.sourceid.org/mailman/listinfo/sso-users