Test Accounts (Per -- Local/Internal IdP Login Account)

[Thorsten Michels]

Am 01.08.2019 um 11:15 schrieb Peter Schober:
> * Thorsten Michels <michels at rhrk.uni-kl.de> [2019-08-01 08:12]:
>> Here
>> https://doku.tid.dfn.de/de:shibidp3testzugang_fuer_externe_admins
>> are two technical solutions for restricting an account to a specific service
>> via activation conditions in the data connectors.
> 
> Thanks for sharing. I don't see that scaling too well with having to
> manage userid-entity pairs for each SP that wants this but maybe those
> arrangements are all short-lived by their nature.

A short-lived access was the intention to this solution.

> I'd have preferred for the IDP to terminate processing for any other
> SPs accessed instead of merely send them along but w/o attributes.
> Currently you risk subject still having access to all SPs that don't
> perform authorization (or charge per subject or whatever). But that
> too may be an edge case.

That's right. At the moment I don't connect to any SP that doesn't at 
least check for "member at ...".

> As for the data: Does your shibgast_resolver_condition.xml resolver
> consist of all static attribute definitions? That way it would be
> fully self-contained in the IDP.

If the question is: "Has the shibgast_resolver_condition.xml to be 
referenced in every DataConnector?", then yes, even the static ones.

> Using an embedded H2 database has been my sqlite alternative for Java
> applications of late, which seems to work well. So pointing that
> seperate resolver to a local H2 database file could be an alternative,
> I guess?
> 
> Though in your case the guest account still has to be created in the
> IDM system (or authn system used by the IDP), at least you don't
> mention anything else.

That's right.

Best regards,
Thorsten

-- 
Thorsten Michels
RHRK
TU Kaiserslautern
Postfach 3049
67653 Kaiserslautern
Tel.: 0631/205-2443