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:]
>>Sent: Saturday, January 22, 2005 11:38 AM
>>To:
>>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.
>
>
>
