ERROR in LOGS IdPv3

[Cantor, Scott]

On 8/24/16, 10:36 AM, "users on behalf of John Morrison" <users-bounces at shibboleth.net on behalf of john.morrison at uadm.uu.se> wrote:

> OK, but what I don't get, I've enabled CAS on our IDP v3 server and
> every CAS'd login is recored into the shibboleth/shibpid database, this
> shouldn't be the case by default?

By default, there are no SAML persistent IDs in the IdP.

If you configure your attribute resolver to produce peristent IDs via the StoredIdConnector, then any resolver run is going to hit that connector, and the relying party identifier is what it is. In SAML, it's an entityID, with CAS it's a location.
    
>    How do I stop this from happening, as you pointed out, using attributes
>    to derive persistentIDs, I have no Idea if our IdP is doing this or not.

Well, it self-evidently is, but if you don't know, certainly nobody else should.

> I don't want CAS'd auths to be recorded in the shibpid at all.

Then you'd have to do something to conditionalize the use of that connector based on whether it's a CAS request, or you move the persistentID support out of the resolver into the non-deprecated NameID generation layer, which replaces the old connector, and I don't think runs when CAS does.
 
>    How did I get into this mess in the first place :)

You configured two features that have never been used together by anybody else, or at least nobody's noted it. The use of databases for this is mostly a non-US thing, and the CAS support is mostly a US thing, so the overlap isn't common.

-- Scott