Re: [regrep] [RS Issue] Internal Vs. External Users

["David Webber \(XML\)" <david@drrw.info>]

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.

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.

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/leave_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/leave_workgroup.php.
>
>
>