David Webber (XML) wrote:
>Matt,
>
>OK - I see that's another issue. Single sign-on. I guess we will need to
>extend the RIM to allow an external user ID and remote reference URL
>(along with potentially a certificate), in addition to our usual RIM
> metadata about person / org. That way - someone can provide a
>pointer to their credentials elsewhere.
>
>We would also need a store to hold those remote refernece URLs
>that we recognise as authentication authorities.... hmmm wonder if
>we can extend the notion of "organization" to incorporate type of
>registration authority?
>
>
David,
We have added single-signon support in the 3.0 specs based upon the SAML
2.0 SSO protocols
which enables a registry to use an external Authentication Authority as
long as it supports SAML 2.
So I think we are already doing what you wisely suggest.
>DW
>
>----- Original Message -----
>From: "Matthew MacKenzie" <>
>To: "David Webber (XML)" <>
>Cc: "Chiusano Joseph" <>; "Farrukh Najmi"
><>; <>
>Sent: Sunday, January 23, 2005 5:18 PM
>Subject: Re: [regrep] [RS Issue] Internal Vs. External Users
>
>
>
>
>>David,
>>
>>The challenge is supporting external identity providers and integrating
>>data about users, groups and organizations into the rest of the
>>information model while honoring the fact that the external provider is
>>authoritative.
>>
>>Authentication is easy. We already support SAML-based SSO in our
>>implementation, and accept the user information as asserted via our
>>SAML/SSO system. The trick is in making User and Organization fully
>>virtual within the registry information model without mirroring or
>>otherwise replicating data from the identity provider. We've managed
>>it, but only because we happen to have a proprietary identity provider
>>that acts as a broker to our customer's actual identity provider(s) and
>>know how it works. The downside to this innovation on our part is that
>>you can't submit a User or Organization via the registry. We politely
>>inform the client that they must seek help from their Identity
>>provider's admin (typically someone, or a process than can access the
>>enterprise's LDAP/Active Directory).
>>
>>-Matt
>>
>>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.
>>>
>>>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" <>
>>>To: "Chiusano Joseph" <>
>>>Cc: "Farrukh Najmi" <>;
>>>
>>>
><>
>
>
>>>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:]
>>>>>>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.
>
>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>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.
>
>
>>>
>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
--
Regards,
Farrukh
