library-walk-in

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

library-walk-in

Jerry Shipman
Hello,

Someone in our library asked me about this issue -- I couldn't really think of a good solution, so thought I'd ask around and see if anyone else had come up with anything. (I haven't looked into it very much - my apologies if I'm asking a stupid question.)

We have a use case where members of the public (i.e. unaffiliated folks without accounts) should be able to make use of our library services when they come on campus. This has (over the past several years) come to include access to e.g. online journals. I think that we're currently accomplishing this by a sort of IP whitelist where the online journal vendor doesn't prompt for authentication when requests come in from our library's network.

I guess that some of the vendors are trying to move away from doing this kind of thing, to e.g. SAML authentication for everybody.
I remember noticing the "library-walk-in" value in the eduPersonAffiliation spec (maybe: https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html#eduPersonAffiliation ). So it seems like somebody has put some thought into this use case in the past.

But I can't imagine how to implement something like that?

The best thing I can picture is that maybe we could somehow configure our IdP such that when users log in from certain IPs on a list of library terminals, to certain SPs on a list of online library services, we don't even ask them to log in, but instead just send over a minimal assertion with e.g. a transient nameId and a eduPersonAffiliation:library-walk-in, and that's it. But the rest of the transactions (from non-library IPs or to non-library SPs) continue go through the normal login page process and get a more verbose assertion. I don't even know if it's possible to implement that?

I guess that I think the best solution is to keep the IP whitelist so that nobody on campus is asked to log in when they access these online library resources, and use the SAML authentication for off-campus access. This is basically what we're doing now, so we wouldn't change anything. But I sort of got the impression from my conversation that this option may be at risk of disappearing. (I didn't look into it very much.)

What do you think? Is there a standard or good approach to this issue?

Thank you,
Jerry

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Cantor, Scott E.
On 8/10/18, 9:16 AM, "users on behalf of Jerry Shipman" <[hidden email] on behalf of [hidden email]> wrote:

> I don't even know if it's possible to implement that?

Yes, it's possible. That was the use case in a nutshell.

> I guess that I think the best solution is to keep the IP whitelist so that nobody on campus is asked to log in when they
> access these online library resources, and use the SAML authentication for off-campus access. This is basically what
> we're doing now, so we wouldn't change anything. But I sort of got the impression from my conversation that this
> option may be at risk of disappearing. (I didn't look into it very much.)

I doubt it, but that's the reason SAML-based access can never be successful. As long as people keep using IP, that will always win. It's frictionless and simple. Any login is not, no matter what the protocol is. As soon as federated access becomes "special", it loses out. People view these sorts of dual paths as a transition aid, but they aren't, they actually prevent any progress because what's there is good enough.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Peter Schober
In reply to this post by Jerry Shipman
* Jerry Shipman <[hidden email]> [2018-08-10 15:16]:

> I guess that some of the vendors are trying to move away from doing
> this kind of thing, to e.g. SAML authentication for everybody.  I
> remember noticing the "library-walk-in" value in the
> eduPersonAffiliation spec (maybe:
> https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html#eduPersonAffiliation
> ). So it seems like somebody has put some thought into this use case
> in the past.
>
> But I can't imagine how to implement something like that?
>
> The best thing I can picture is that maybe we could somehow
> configure our IdP such that when users log in from certain IPs on a
> list of library terminals, to certain SPs on a list of online
> library services, we don't even ask them to log in, but instead just
> send over a minimal assertion with e.g. a transient nameId and a
> eduPersonAffiliation:library-walk-in, and that's it. But the rest of
> the transactions (from non-library IPs or to non-library SPs)
> continue go through the normal login page process and get a more
> verbose assertion. I don't even know if it's possible to implement
> that?

FWIW, I'm now trying to document one such use-case for our community
where a publisher only accepts SAML now but some of the libraries have
"walk-in" users who do not have personal credentials to log in with.
So use from within certain IP ranges will be possible by going through
the usual SAML flow of accessing the SP, chosing to log in, picking
the IDP to log in at, then transparently being logged it to the IDP
due to "IP authentication" with attributes being sent to the SP as
usual.

This all works fine, pretty much out of the box: (Thanks!)

1. Activate IP authn in idp.properties by setting
   idp.authn.flows= IPAddress|Password
2. Enter the IP ranges and the surrogate user to use in
   conf/authn/ipaddress-authn-config.xml, as per
   https://wiki.shibboleth.net/confluence/display/IDP30/IPAddressAuthnConfiguration#IPAddressAuthnConfiguration-GeneralConfiguration
3. Add a surrogate user somewhere, with minimal attributes and/or
   configure the IDP to assign the desired attributes to that account.

What I'm struggling with atm is preventing generation of ePTID (based
on RequestedAttribute elements in metadata) or persistent NameIDs
(based on NameIDFormat elements in metadata) or pairwise-id/subject-id
(based on EntityAttribute elements in metadata) for such logins from
the surrogate account, as I cannot guarantee the "non-transferrable"
property of such identifiers with IP-based authentication.

I.e., other than ePSA=library-walk-in@%{idp.scope} and
ePE=common-lib-terms (and maybe transient NameIDs) I don't want to
release anything for this account, ever.

Now overriding the NameID format selection in relying-party.xml is
certainly possible but scales poorly. Same with DenyValueRules in the
attribute filter for any unwanted attributes, or ones based on the
principal name of the surrogate user account.
I don't think tuning the resolver using relyingParty attributes or
acticationConditions will help her, either.

Am I missing something? Or should I create one rule specific to the
surrogate user account and add DenyValueRules for all attributes the
IDP is likely to release?

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Peter Schober
* Peter Schober <[hidden email]> [2019-02-26 17:44]:
> Am I missing something? Or should I create one rule specific to the
> surrogate user account and add DenyValueRules for all attributes the
> IDP is likely to release?

Even then persistent NameIDs would still be released based on
NameIDFormat elements in metadata (since not releasing the underlying
attribute will not prevent releasing the derived NameID), and
overriding them would require enumerating SPs.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Cantor, Scott E.
In reply to this post by Peter Schober
On 2/26/19, 11:44 AM, "users on behalf of Peter Schober" <[hidden email] on behalf of [hidden email]> wrote:

> I don't think tuning the resolver using relyingParty attributes or
> acticationConditions will help her, either.

I would think an activation condition common to a lot of the components that checked for IP authentication or just the particular subject name that was used for the dummy login would do a decent job at it.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Peter Schober
* Cantor, Scott <[hidden email]> [2019-02-26 18:19]:
> I would think an activation condition common to a lot of the
> components that checked for IP authentication or just the particular
> subject name that was used for the dummy login would do a decent job
> at it.

So far the convoluted way to do things seems to be to add
DenyValueRules (to prevent other attriutes from being released) within
  <PolicyRequirementRule xsi:type="PrincipalName" value="walk-in"/>

And adding an activation condition to prevent generation of persistent
NameIDs when an uid attr (or the SubjectName) is NOT the one
configured in conf/authn/ipaddress-authn-config.xml (i.e., not the
walk-in surrogate user).

The bean "authn/IPAddress" already has a few specials configured in
conf/authn/general-authn.xml (e.g. p:lifetime="PT60S") so maybe an RFI
would be suppressing any persistent NameID generation right there,
too, since those persistent NameIDs couldn't possibly be
spec-compliant with IP authn (ignoring the theoretic possibility of
someone having a 1:n mapping of person to IP addresses, and added them
all to shibboleth.authn.IPAddress.Mappings)?

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Cantor, Scott E.
On 2/26/19, 12:34 PM, "users on behalf of Peter Schober" <[hidden email] on behalf of [hidden email]> wrote:

> So far the convoluted way to do things seems to be to add
> DenyValueRules (to prevent other attriutes from being released) within
>  <PolicyRequirementRule xsi:type="PrincipalName" value="walk-in"/>

You can also just disable resolving those attributes. That's perhaps more elegant than filtering. They serve the same purpose but preventing the resolution makes for a more global change to the internal system state, addresses IDs generated from the resolver, etc.

> And adding an activation condition to prevent generation of persistent
> NameIDs when an uid attr (or the SubjectName) is NOT the one
> configured in conf/authn/ipaddress-authn-config.xml (i.e., not the
> walk-in surrogate user).

That's why it feels like disabling the attributes at their source is more powerful. That short-circuits anything happening that high in the stack.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Peter Schober
* Cantor, Scott <[hidden email]> [2019-02-26 18:54]:

> On 2/26/19, 12:34 PM, [hidden email] wrote:
> > So far the convoluted way to do things seems to be to add
> > DenyValueRules (to prevent other attriutes from being released) within
> >  <PolicyRequirementRule xsi:type="PrincipalName" value="walk-in"/>
>
> You can also just disable resolving those attributes. That's perhaps
> more elegant than filtering. They serve the same purpose but
> preventing the resolution makes for a more global change to the
> internal system state, addresses IDs generated from the resolver,
> etc.
>
> > And adding an activation condition to prevent generation of persistent
> > NameIDs when an uid attr (or the SubjectName) is NOT the one
> > configured in conf/authn/ipaddress-authn-config.xml (i.e., not the
> > walk-in surrogate user).
>
> That's why it feels like disabling the attributes at their source is
> more powerful. That short-circuits anything happening that high in
> the stack.

Well, I had the feel that having an essentially self-contained
AttributeFilterPolicy dealing with this one specific case-case
(walk-in user surrogate) would be much cleaner than infecting
potentially each and every AttributeDefinition in the resolver with
special-case custom references to "notLibraryWalkIn" (where it's
convievable that some filter rule may release the attribute).

But attaching activationConditionRef XML attributes to a bunch
of AttributeDefinition in the resolver instead is probably not much
worse:
In either case care should be taken that the subject does not have
assigned most/any of the attributes/data in the source system.

To summarize:

I now have a simple bean defined in conf/global.xml (at first I used a
custom file and made this reloadable via conf/services.xml in
id="shibboleth.NameIdentifierGenerationResources" since I intended to
use this to control NameID behaviour primarily, but then the bean
defined there wasn't seen from the resolver) to use as an activation
condition when the subject is NOT the walk-in surrogate subject:

  <bean id="notLibraryWalkIn" parent="shibboleth.Conditions.NOT">
      <constructor-arg>
          <bean parent="shibboleth.Conditions.SubjectName" c:collection="#{'walk-in'}" />
      </constructor-arg>
  </bean>

In conf/saml-nameid.xml instead of using the default of

  <ref bean="shibboleth.SAML2PersistentGenerator" />

I now have:

  <bean parent="shibboleth.SAML2PersistentGenerator"
    p:activationCondition-ref="notLibraryWalkIn" />

which suppresses generation of persistent NameIDs for walk-ins.

And for attributes I now have added an
activationConditionRef="notLibraryWalkIn" XML attribute to a handful
of AttributeDefinition elements in the resolver that "create" data
dynamically, mostly for the subject-id, pairwise-id and the legacy
eduPersonTargetedID SAML Attributes.

Many of the attributes that should be prevented from being released
are done so by making sure the source system does not have any data
for the selected walk-in account. (In this case that also involved
creating an LDAP account with objectClass 'account' which only has a
single mandatory attribute 'uid', plus the eduPerson aux objectclass
for the eduPersonScopedAffiliation and eduPersonEntitlement
attributes, but nothing else.)

That still amounts to touching quite a few parts (which scales badly
when I have to support dozens of IDPs in applying those changes, and
those changes then depend on the specifics of their resolver config)
but we'll see how this goes.

Thanks for the help,
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Cantor, Scott E.
On 2/26/19, 2:42 PM, "users on behalf of Peter Schober" <[hidden email] on behalf of [hidden email]> wrote:

> Well, I had the feel that having an essentially self-contained
> AttributeFilterPolicy dealing with this one specific case-case
> (walk-in user surrogate) would be much cleaner than infecting
> potentially each and every AttributeDefinition in the resolver with
> special-case custom references to "notLibraryWalkIn" (where it's
> convievable that some filter rule may release the attribute).

I was imagining it mainly at the DataConnector layer as long as things are configured to gracefully handle the null cases (or you could supply alternative connectors as failovers that supply the specific static data for that identity).

Anyway, the main point was, if the NameID layer has no data to depend on, it won't run and doesn't need to be told not to.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Peter Schober
* Cantor, Scott <[hidden email]> [2019-02-26 20:50]:
> I was imagining it mainly at the DataConnector layer as long as
> things are configured to gracefully handle the null cases (or you
> could supply alternative connectors as failovers that supply the
> specific static data for that identity).
>
> Anyway, the main point was, if the NameID layer has no data to
> depend on, it won't run and doesn't need to be told not to.

Right, but I couldn't use this on the DataConnector layer as I still
need the ePSA and ePE attributs for the given account.
(I.e., I used an actual data source in order to save me from having to
conditionally create the necessary data within the resolver.)

But of course I could create that data within the resolver (e.g. in a
mapped attribute definition) and forgo the data connector lookups, but
that seemed to amount to yet more boilerplate XML to add.

Also, I'm not using a Principal connector (but instead I use the LDAP
DataConnector to get case normalization for the entered username in
the login form for free, via case-insensitive searches but
case-preserving search result values) so I guess I'd have to
retructure that, too?  I.e., the subject will be populated during the
authn/IPAddress flow (AFAIU) and in order to access it within the
resolver I'd have to add a Principal type attribute definition (and
ideally this one should only run for the walk-in user, so I'd have to
add another condition without the NOT in it)?

But I guess in general it may be worth simply not running *all* of the
DataConnectors for the walk-in user and instead synthesize any needed
attributes within the resolver from the subject name alone.
I'd have to try that to see whether that makes for less config or
fewer changes.

Thanks again,
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: library-walk-in

Peter Schober
In reply to this post by Cantor, Scott E.
Follow-up to resolving only desired attributes for the technical
"walk-in users" account w/o having to worry about any other
(undesired) attributes that the resolver may hand out
indiscriminately:

* Cantor, Scott <[hidden email]> [2019-02-26 20:50]:
> I was imagining it mainly at the DataConnector layer as long as
> things are configured to gracefully handle the null cases (or you
> could supply alternative connectors as failovers that supply the
> specific static data for that identity).
>
> Anyway, the main point was, if the NameID layer has no data to
> depend on, it won't run and doesn't need to be told not to.

I've now documented the process to do just that, without creating an
actual account in any source systems while preventing any
DataConnectors from running for that subject, as suggested by Scott:

https://wiki.univie.ac.at/display/federation/IP-Authentication

It does reference our own local documentation in a few places for
context and so is currently hosted within our own wiki but if there's
interest I can move this into the Shibboleth wiki somewhere, too.

Happy to answer questions about this on this list, esp if anything is
still unclear or wrong.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]