Feb 12, 2007

From OpenLiberty.org Wiki

Back to Meeting Minutes←

DUE TO A CRASH ON OUR MINUTE KEEPER'S MACHINE, THESE MINUTES ARE NOT COMPLETE.

Present: Scott Cantor, George, Conor Cahill, Chad, Eric Tiffany, Diego, Curtis Jones, Asa Hardcastle

Website use case

Scott: primary target is WSC

Conor: SSO using SAML - new site takes the DS assertion and invokes the service

Diego: web hosted is less complicated effort - osiris - initial basis for evaluating services evaluated in a web hosted environment. better control of the variables

Scott: Discovery is a hell of a lot more complicated than the sso

Scott: happy to let the project focus on consumer oriented - would like the code base for token service use cases

Conor: instantiate an epr, go to ssos and get the token needed for the epr.

Scott: do a wsf enabled call using saml

Conor: after disco, use epr to invoke a wsf service

Scott: registration service not important for openSAML, they use SAML

Scott: only danger - how you describe what you are doing - the more concrete the use case, the more pigeon holed it becomes - afraid that a use case

Conor: difference between use case and "this is what we did" "invoke id-wsf layer that allows us to invoke any id-wsf service"

Curtis - should we have multiple use cases

Conor - can have a million use cases, doesn't

Curtis - categories of use case

Scott - focus on architectural and less on the application layer - where are the different boxes -described web hosted wsc behind a disco using sso

Conor: typical off the shelf - scott has known locations of services

Scott - meta search, relationships between business users. e.g. - google scholars searching information providers. We want the user security context to be propagated in a safe way throughout the

Diego - creating different federations through different services - using a lingua franca - meta info about which idp you need to contact to get a certain type f - has a first prototype running

Scott - orthogonal - carving disco out is useful to Scott because.

Lots of ways to feed info related to disco into an infrastructure, but

liberty disco service is keyed to users - most of the use cases in front of scott are not keyed to users - mostly infrastructure talking with infrastructure - users credentials flowing

epr (as an object) - tells you the sec requirements dealing with ws-sec policy will become important

WEB HOSTED WSC - 1.that uses discover 2.another that uses SSOS CLIENT WSC (involves AS) -

SOAP / XML LAYERING

Conor - do we want it to be pluggable into the off the shelf SOAP tools? George - insert a handler into the chain - can do WSDL! building a WSDL without any reference to anything ID-WSF -- when you get your stubs you go - heres the id-wsf header handler -

inject filters/handlers into the process but when your application gets the message it can be difficult to get at the info.

Managing the context -

axis supports multiple data bindings -

What is our goal?

Conor: one of the goals is to support a web server environment. If we make this decision, the work we do is not likely

Invoke web services from behind a SSO

If you use AXIS then we will write AXIS specific code in order to develop pieces - assumption that in AXIS 2 that the interface to the SOAP layer is AXIUM

Actually you are in DOM mode - get a SOAP element

XML Tooling library - ability to get SAML assertion wrappers

ID-WSF Tooling layer - want to support sso and invoke billing, sso, printing, and profile

issue with not providing a

WS code independently

interesting discussion - lets pick the web server environment - want

FUTURE: Conor's Suggestion: On top of AXIS as a second stage thing - move forth - some of us interested in another environment look at how we can re-use in a different environment. // supporting WSDL - long term goal //server side

move forward -

• Both libraries have "element proxies" can wrap an arbitrary DOM, if you don't know what the

- write classes to get type safe - type neutral interfaces - if you care about type safe interfaces, you must write your own objects - wsf-layer - xml objects to model soap headers not hard.

CONOR: build in the appropriate switch points to deal with multiple versions of the framework - idwsf1 and idwsf2 -- not that hard to support both - for the most part the same info is there, just in different headers.