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

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

Farrukh,

OK  makes sense - and therefore Adobe should be
implementing SAML 2.0 between their proprietary
registration server and the registry - and that then
should put them in alignment?!

 ; -)

DW

----- Original Message ----- 
From: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>
To: <regrep@lists.oasis-open.org>
Sent: Saturday, January 22, 2005 5:48 PM
Subject: Re: [regrep] [RS Issue] Internal Vs. External Users


> 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" <mattm@adobe.com>
> >To: "David Webber (XML)" <david@drrw.info>
> >Cc: "Chiusano Joseph" <chiusano_joseph@bah.com>; "Farrukh Najmi"
> ><Farrukh.Najmi@Sun.COM>; <regrep@lists.oasis-open.org>
> >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" <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_workgrou
p
> >>
> >>
> >.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_workgrou
p
> >>
> >>
> >.php.
> >
> >
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> -- 
> 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/leave_workgroup.php.
>
>
>