OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Matthew MacKenzie wrote:

> I am in favour of cleanly separating functions such as user management 
> from registry operations.  

I am too. As, I am sure, is everyone else in the TC.

> User/Identity management is a complex and involved area of 
> functionality that this spec really is not scoped on.

I agree. We did what we had to when there were no standards available 
for Single Signon etc.

> I am trying to warn everyone what happens when all of a sudden they 
> find themselves synchronizing 10's of thousands of users from an LDAP 
> server multiple times a day just to facilitate a handful of RS queries 
> that are used relatively rarely. I have dabbled with every kind of 
> solution to this -- from synchronization, to on-demand provisioning to 
> full delegation of user management to an external system.  I'll tell 
> the story for a beer, complete with the conclusion.

+1 on the problem and you are not alone in appreciating its import.

> One thing is for certain, the SAML stuff is a god send and a huge step 
> in the right direction.  Without it, most registry implementations 
> could become major security holes when deployed to a broad user base.


The entire purpose of the SAML feature is to eliminate the need for 
registry to do Identity Provisioning and instead leverage industrial 
strength Identity Provisioning solutions such as Access Manager products.

The only questions left is what to do with our existing Identity 
Provisioning capabilities. My solution is to leave it intact for 
following reasons:

-SAML is not a required feature for Registry Lite conformance profile 
(you need an alternative if SAML is not implemented)

-We need to provide an incremental migration from current registry 
native Identity Provisioning to SAML based Identity Provisioning.

I can see that over time (probably in version 4) we will get rid of 
registry native Identity Provisioning al together and require support of 
Registry SAML Profile.
But I still feel we need to hold on to the registry native Identity 
Provisioning in version 3.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]