[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] [RS Issue] Internal Vs. External Users
<Quote> As I said in response to Joe's message on this thread I think the only interfaces related to IdentityProvider / AuthenticationAuthority we need to define are those defined by SAML 2 SSO protocols that are already being used in the 3.0 specs and that we should not specify a different interface. Thanks. </Quote> Read my lips: No New Interfaces!!!! ;) Kind Regards, Joseph Chiusano Booz Allen Hamilton Strategy and Technology Consultants to the World > -----Original Message----- > From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] > Sent: Saturday, January 22, 2005 5:35 PM > To: David Webber (XML) > Cc: Matthew MacKenzie; Chiusano Joseph; regrep@lists.oasis-open.org > Subject: Re: [regrep] [RS Issue] Internal Vs. External Users > > David Webber (XML) wrote: > > >Gentle folks - I see in the OMAR implementation we have the > certificate > >management function. This is very useful and an excellent > supporting > >service for Hermes and issuing of CPA certificates to partners, and > >more. > > > > > For those not familiar with OMAR it is the internal name of > the freebXML Registry project. > > >Is this not the type of abstraction we need here? E.g. a neutral > >registry service that supports authentication and certificate > >management et al - but we do not need to specify exactly how this is > >done - just the types of service provided. > > > > > As I said in response to Joe's message on this thread I think > the only interfaces related to IdentityProvider / > AuthenticationAuthority we need to define are those defined > by SAML 2 SSO protocols that are already being used in the > 3.0 specs and that we should not specify a different > interface. Thanks. > > >That way implementers can provide extensions to their favourite > >directory services of choice - while at the same time > allowing a higher > >level set of consistent services to be provided by and between > >registry(s) and associated services. > > > >Do we already have the makings of that service interface somewhere? > > > >Thanks, DW > > > >----- Original Message ----- > >From: "Matthew MacKenzie" <mattm@adobe.com> > >To: "Chiusano Joseph" <chiusano_joseph@bah.com> > >Cc: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>; > ><regrep@lists.oasis-open.org> > >Sent: Sunday, January 23, 2005 3:06 PM > >Subject: Re: [regrep] [RS Issue] Internal Vs. External Users > > > > > > > > > >>At the core of my comment is an understanding of facts in the > >>enterprise > >>setting: An ebXML registry WILL NOT be an identity > provider, unless of > >>course a very large software company decides to make a product and > >>successfully market it into many enterprise customers. I > doubt this > >>would happen, so we need to be very specific in saying that > Identity > >>management is not a registry function. By putting some kind of > >>abstraction in the specification, we still allow registries > to support > >>being a minimal identity provider for small or pilot > installations but > >>do not get in the way of serious enterprise installations either. > >> > >>I have yet to encounter a paying customer of ebXML registry > that was > >>especially happy about having an extra user database to > support. In > >>fact, since early days at XML Global, LDAP/ActiveDirectory > integration > >>has been a top ask. > >> > >>-Matt > >>Chiusano Joseph wrote: > >> > >> > >> > >>>Farrukh, > >>> > >>>Is the bottom-line question here "should the registry > should define > >>>an abstract PrincipalProvider service, and treat external and > >>>internal users equally as something that may or may not be > managed by > >>>the registry?" rather than the way it is described in section 11.7? > >>> > >>>If so, I believe the definition/usage of a > PrincipalProvider service > >>>should be left as an implementation choice. There may be > >>>implementations that use a registry only locally, and may > not need to > >>>use external identity providers. On a related note, I would not > >>>consider the registry's management of users (a capability > since v1) > >>>as synonymous with an identity provider in terms of what SAML and > >>>Liberty Alliance enable. > >>> > >>>Kind Regards, > >>>Joseph Chiusano > >>>Booz Allen Hamilton > >>>Strategy and Technology Consultants to the World > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] > >>>>Sent: Saturday, January 22, 2005 11:38 AM > >>>>To: regrep@lists.oasis-open.org > >>>>Subject: [regrep] [RS Issue] Internal Vs. External Users > >>>> > >>>>Matt sent following comment on section 11.7 that > describes Internal > >>>>Vs. > >>>>External Users. > >>>> > >>>>"This section exists, IMO, due to poor design. Why is > there even a > >>>>concept of internal and external users and organizations? The > >>>>registry should define an abstract PrincipalProvider service, and > >>>>treat external and internal users equally as something > that may or > >>>>may not be managed by the registry." > >>>> > >>>>The registry historically since version 1 has served in > the roles of > >>>>an Identity Provider (manages users) and an > Authentication Authority > >>>>( validates user credentials). Thus a registry prior to version 3 > >>>>allowed users to be stored internal to the registry. > >>>> > >>>>With version 3 we allow the Identity Provider and Authentication > >>>>Authority functions to be provided by an external SAML Authority > >>>>such as an Access Manager service. > >>>>Depending upon deployment situations a registry MAY manage users > >>>>itself or leverage an external service to do so. > >>>> > >>>>This section is defining the behavior of how to handle > cases where a > >>>>user is bweing managed by an external service rather than the > >>>>registry. > >>>> > >>>>If you have a specific proposal on how to address this > issue please > >>>>share and we can review the details. Thanks. > >>>> > >>>>-- > >>>>Regards, > >>>>Farrukh > >>>> > >>>> > >>>>To unsubscribe from this mailing list (and be removed from the > >>>>roster of the OASIS TC), go to > >>>>http://www.oasis-open.org/apps/org/workgroup/regrep/members/le > >>>>ave_workgroup.php. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>To unsubscribe from this mailing list (and be removed from > the roster > >>>of > >>> > >>> > >the OASIS TC), go to > >http://www.oasis-open.org/apps/org/workgroup/regrep/members/l > eave_workgroup.php. > > > > > >>> > >>> > >>> > >>To unsubscribe from this mailing list (and be removed from > the roster > >>of > >> > >> > >the OASIS TC), go to > >http://www.oasis-open.org/apps/org/workgroup/regrep/members/l > eave_workgroup.php. > > > > > >> > >> > >> > > > > > > > > > > > -- > Regards, > Farrukh > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]