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

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

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/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