attributes from external auth

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

attributes from external auth

Jason Pyeron
We have an identity source, which provides the unique user id and associated metadata for that user. It is "expensive" to communicate with it. Our external auth (Shibboleth Identity Provider 4.0.1) is attempting to store attributes at the same time as the principal is stored. For argument sake, let's assume it free to get the attributes at the same time as the uid, but double the cost to fetch them subsequently [6].

Reading the mailing list archives [1,2,3] it seems what we want to do is not possible. But the documentation [4] for external auth outputs indicates it should be able to set the attributes. To quote:

> Any IdPAttribute objects supplied will be processed by the AttributeFilter
> service as "inbound" data. If at least one value in the "authnAuthorities"
> attribute is supplied, it is set as the "issuer" of the attributes for the
>  purposes of the filter evaluation.

We have increased the logging to DEBUG on net.shibboleth.idp.attribute, which resulted in the confirmation that the attributes were set, then later filtered away.

Since the attributes were not set, we stepped back and used some hard coded example (template) attribute definitions. This confirmed that our IdP was happy to provide the values to a SP.

Is it true that external auth can provide attributes in v4 (was true in v2 per mailing list) as implied by the docs, source code, and logs?

If so, what are the possible (and preferred) mechanisms to define them and (not) filter them away? ScriptedAttribute, ContextDerived, Simple with a InputAttributeDefinition/InputDataConnector, or something else?

Our current path of investigation is using the InputDataConnector [5], but we have been unsuccessful in identifying what to put as the value for "ref" to source from the attributes returned from the shibboleth.authn.External.externalAuthnPath being used by configuration idp.authn.flows=External. We have even restarted the server in debug, stopping on ComponentInitializationException to inspect what sources are available.

It is quite likely that I am going about this all wrong.

Thoughts and suggestions requested.

Respectfully,

Jason Pyeron


1: http://shibboleth.net/pipermail/users/2014-December/018489.html
2: http://shibboleth.net/pipermail/users/2014-December/018412.html
3: http://shibboleth.net/pipermail/users/2016-August/031039.html
4: https://wiki.shibboleth.net/confluence/display/IDP4/ExternalAuthnConfiguration#ExternalAuthnConfiguration-Outputs
5: http://shibboleth.net/pipermail/users/2020-August/047909.html
6: Connection cost much greater than query cost


--
Jason Pyeron  | Architect
PD Inc        |
10 w 24th St  |
Baltimore, MD |
 
.mil: [hidden email]
.com: [hidden email]
tel : 202-741-9397



--
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: attributes from external auth

Cantor, Scott E.
> Reading the mailing list archives [1,2,3] it seems what we want to do is not possible. But the documentation [4] for
> external auth outputs indicates it should be able to set the attributes. To quote:

Messages from 2014 don't have much relevance compared to actual documentation when you're talking about not even the same major release.

>    Is it true that external auth can provide attributes in v4 (was true in v2 per mailing list) as implied by the docs, source
> code, and logs?

Yes.

>  If so, what are the possible (and preferred) mechanisms to define them and (not) filter them away? ScriptedAttribute,
> ContextDerived, Simple with a InputAttributeDefinition/InputDataConnector, or something else?

Attributes obtained during authentication are stored inside the Subject and tracked as part of the AuthenticationResult for that method. If you're trying to make use of them later or pass them out to an SP, you need the Subject DataConnector [1] to pull them out for that purpose.

I don't recall the External login method filtering attributes. Proxying via SAML does, but I didn't think External did, don't recall offhand. If it says it does or logs say it does then it does. Perhaps it does only in the case where an authenticationAuthority is supplied.

>    Our current path of investigation is using the InputDataConnector [5],

That element is used to express dependencies between connectors, it is not a connector or a definition of anything. It's a line in the graph, not a node.

-- 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: attributes from external auth

Jason Pyeron
Thanks! This seems to have steered me in the right direction. I may have found a bug or I am just thinking wrong. Will follow up after my next code change.

> From: Cantor, Scott
> Sent: Wednesday, January 13, 2021 3:08 PM
>
> > Reading the mailing list archives ... SNIP
> Messages from 2014 don't have much relevance compared to actual documentation when you're talking


Agreed, was just showing what I had tried.

>
> >    Is it true that external auth can provide attributes in v4 (was true in v2 per mailing list) as
> implied by the docs, source
> > code, and logs?
>
> Yes.
>
> >  If so, what are the possible (and preferred) mechanisms to define them and (not) filter them away?
> ScriptedAttribute,
> > ContextDerived, Simple with a InputAttributeDefinition/InputDataConnector, or something else?
>
> Attributes obtained during authentication are stored inside the Subject and tracked as part of the
> AuthenticationResult for that method. If you're trying to make use of them later or pass them out to
> an SP, you need the Subject DataConnector [1] to pull them out for that purpose.

When using:

        <AttributeDefinition xsi:type="Simple"
                id="eduPersonNickname">
                <InputDataConnector ref="passthroughAttributes"
                        attributeNames="eduPersonNickname" />
        </AttributeDefinition>

        <DataConnector id="passthroughAttributes"
                xsi:type="Subject" exportAttributes="eduPersonNickname" />

I no longer have errors in the logs, but I get:

<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>xyzzy1</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>[hidden email]</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>[hidden email]</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>[hidden email]</saml2:AttributeValue>
  </saml2:Attribute>
</saml2:AttributeStatement>

With the following log messages.

DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:431] - Attribute Resolver 'ShibbolethAttributeResolver': Resolving dependencies for 'eduPersonNickname'
DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:440] - Attribute Resolver 'ShibbolethAttributeResolver': Finished resolving dependencies for 'eduPersonNickname'
DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:137] - Attribute Definition 'eduPersonNickname': produced an attribute with no values
DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:335] - Attribute Resolver 'ShibbolethAttributeResolver': Attribute definition 'eduPersonNickname' produced an attribute with 0 values


This is progress - I will continue to read and debug.

I am suspecting the registration of attributes, like the following are being ignored. The Subject Data Connector [7] says "The Subject DataConnector exposes IdPAttribute objects contained within Java Subject(s)", but the IdPAttribute collection is not in the Subject or Principals.

        Collection<IdPAttribute> attrs=new ArrayList<IdPAttribute>();
        IdPAttribute attr;
        attr=new IdPAttribute("eduPersonNickname");
        attr.setValues(Collections.singleton(new StringAttributeValue("Bob Barker 1")));
        attrs.add(attr);
        attr=new IdPAttribute("ignoredAttribute");
        attr.setValues(Collections.singleton(new StringAttributeValue("Bob Barker 3")));
        attrs.add(attr);
        request.setAttribute(ExternalAuthentication.ATTRIBUTES_KEY, attrs);

ExternalAuthenticationImpl.java:
        attr = request.getAttribute(ATTRIBUTES_KEY);
        if (attr != null && attr instanceof Collection<?>) {
            extContext.getSubcontext(AttributeContext.class, true).setUnfilteredIdPAttributes(
                    (Collection<IdPAttribute>) attr);
            extContext.getSubcontext(AttributeContext.class).setIdPAttributes(
                    (Collection<IdPAttribute>) attr);
        }

I will change the code to use javax.security.auth.Subject [8].

>
> I don't recall the External login method filtering attributes. Proxying via SAML does, but I didn't
> think External did, don't recall offhand. If it says it does or logs say it does then it does. Perhaps
> it does only in the case where an authenticationAuthority is supplied.

With a baseline test using:

        <AttributeDefinition id="eduPersonNickname"
                xsi:type="Template">
                <InputAttributeDefinition ref="uid" />
                <Template>name ${uid}</Template>
        </AttributeDefinition>

I get:

<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml2:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>[hidden email]</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>[hidden email]</saml2:AttributeValue>
  </saml2:Attribute>

  <!-- eduPersonNickname = name ${uid} -->
  <saml2:Attribute FriendlyName="eduPersonNickname" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.2" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>name xyzzy1</saml2:AttributeValue>
  </saml2:Attribute>

  <saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>xyzzy1</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>[hidden email]</saml2:AttributeValue>
  </saml2:Attribute>
</saml2:AttributeStatement>

7: https://wiki.shibboleth.net/confluence/display/IDP4/SubjectDataConnector
8: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/security/auth/Subject.html


--
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: attributes from external auth

Cantor, Scott E.
I was incorrect, it does filter anything inbound, and that should be self-evident from the log. With no issuer, the only way to get it to accept them is with "any" policy rules or with an inbound Direction rule.

> "The Subject DataConnector exposes IdPAttribute objects contained within Java Subject(s)", but the IdPAttribute
> collection is not in the Subject or Principals.

Not when it's filtered out to start with, no. If it weren't, it would be there.

-- 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: attributes from external auth

Jason Pyeron
In reply to this post by Jason Pyeron
Solved! Would an update to https://wiki.shibboleth.net/confluence/display/IDP4/ExternalAuthnConfiguration "external interface example in JSP" be welcome?

> From: Jason Pyeron
> Sent: Wednesday, January 13, 2021 5:40 PM
>
> Thanks! This seems to have steered me in the right direction. I may have found a bug or I am just
> thinking wrong. Will follow up after my next code change.
>
> > From: Cantor, Scott
> > Sent: Wednesday, January 13, 2021 3:08 PM
> >
<snip/>

> >
> > >    Is it true that external auth can provide attributes in v4 (was true in v2 per mailing list) as
> > implied by the docs, source
> > > code, and logs?
> >
> > Yes.
> >
> > >  If so, what are the possible (and preferred) mechanisms to define them and (not) filter them
> away?
> > ScriptedAttribute,
> > > ContextDerived, Simple with a InputAttributeDefinition/InputDataConnector, or something else?
> >
> > Attributes obtained during authentication are stored inside the Subject and tracked as part of the
> > AuthenticationResult for that method. If you're trying to make use of them later or pass them out to
> > an SP, you need the Subject DataConnector [1] to pull them out for that purpose.
>
> When using:
>
> <AttributeDefinition xsi:type="Simple"
> id="eduPersonNickname">
> <InputDataConnector ref="passthroughAttributes"
> attributeNames="eduPersonNickname" />
> </AttributeDefinition>
>
> <DataConnector id="passthroughAttributes"
> xsi:type="Subject" exportAttributes="eduPersonNickname" />
>
<snip/>

>
> DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:431] - Attribute Resolver
> 'ShibbolethAttributeResolver': Resolving dependencies for 'eduPersonNickname'
> DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:440] - Attribute Resolver
> 'ShibbolethAttributeResolver': Finished resolving dependencies for 'eduPersonNickname'
> DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:137] - Attribute Definition
> 'eduPersonNickname': produced an attribute with no values
> DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:335] - Attribute Resolver
> 'ShibbolethAttributeResolver': Attribute definition 'eduPersonNickname' produced an attribute with 0
> values
>
Fixed by switching to request.setAttribute(ExternalAuthentication.SUBJECT_KEY,new Subject(false, principals, Collections.EMPTY_SET, Collections.EMPTY_SET));

Where principals is a collection of the UsernamePricipal and IdPAttributePrincipal objects.

>
> This is progress - I will continue to read and debug.
>
> I am suspecting the registration of attributes, like the following are being ignored. The Subject Data
> Connector [7] says "The Subject DataConnector exposes IdPAttribute objects contained within Java
> Subject(s)", but the IdPAttribute collection is not in the Subject or Principals.
>
> Collection<IdPAttribute> attrs=new ArrayList<IdPAttribute>();
> IdPAttribute attr;
> attr=new IdPAttribute("eduPersonNickname");
> attr.setValues(Collections.singleton(new StringAttributeValue("Bob Barker 1")));
> attrs.add(attr);

        principals.add(new IdPAttributePrincipal(attr));

> attr=new IdPAttribute("ignoredAttribute");
> attr.setValues(Collections.singleton(new StringAttributeValue("Bob Barker 3")));
> attrs.add(attr);


        principals.add(new IdPAttributePrincipal(attr));

        principals.add(new UsernamePrincipal("xyzzy2a"));

        request.setAttribute(ExternalAuthentication.SUBJECT_KEY,new Subject(false, principals, Collections.EMPTY_SET, Collections.EMPTY_SET));

and eliminated:
> request.setAttribute(ExternalAuthentication.ATTRIBUTES_KEY, attrs);

Because it is ignored by the <DataConnector xsi:type="Subject" ... >

Which results in:

<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
  <!-- attribute from the external auth -->
  <saml2:Attribute FriendlyName="eduPersonNickname" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.2" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>Bob Barker 1</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>xyzzy2a</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute FriendlyName="eduPersonPrincipalName" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>[hidden email]</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>[hidden email]</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <saml2:AttributeValue>[hidden email]</saml2:AttributeValue>
  </saml2:Attribute>
</saml2:AttributeStatement>

--
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: attributes from external auth

Cantor, Scott E.
On 1/13/21, 6:39 PM, "users on behalf of Jason Pyeron" <[hidden email] on behalf of [hidden email]> wrote:

> Would an update to "external interface example in JSP" be welcome?

Only as an alternative, not as a "fix", there's nothing broken about the defined way.

>    Because it is ignored by the <DataConnector xsi:type="Subject" ... >

It is not. But it has to get past the filter. If you prefer to pass them in with more code instead of with more configuration, that's fine, they're both supported.

-- 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: attributes from external auth

Jason Pyeron
> From: Cantor, Scott
> Sent: Wednesday, January 13, 2021 6:47 PM
>
> On 1/13/21, 6:39 PM, " Jason Pyeron" wrote:
>
> > Would an update to "external interface example in JSP" be welcome?
>
> Only as an alternative, not as a "fix", there's nothing broken about the defined way.

Thanks again, I was stuck for almost 2 days.

https://wiki.shibboleth.net/confluence/display/IDP4/ExternalAuthnConfiguration

External interface with attributes in JSP
=========================================

<%@ page pageEncoding="UTF-8" %>
<%@ taglib uri="http://www.springframework.org/tags" prefix="spring" %>
<%@ page import="net.shibboleth.idp.authn.*" %>
<%@ page import="net.shibboleth.idp.attribute.*"%>
<%@ page import="net.shibboleth.idp.authn.principal.*"%>
<%@ page import="java.util.*"%>
 
<%
try {
    final String key = ExternalAuthentication.startExternalAuthentication(request);
 
    HashSet<Principal> principals=new HashSet<Principal>();
 
    principals.add(new UsernamePrincipal("bbarker"));
 
    //<DataConnector xsi:type="Subject" exportAttributes="mail eduPersonNickname" id="myId" />
    //<AttributeDefinition ... <InputDataConnector ref="myId" ...
    IdPAttribute attr=new IdPAttribute("eduPersonNickname");
    attr.setValues(Collections.singleton(new StringAttributeValue("Bob Barker")));
    principals.add(new IdPAttributePrincipal(attr));
 
    attr=new IdPAttribute("mail");
    attr.setValues(Collections.singleton(new StringAttributeValue("[hidden email]")));
    principals.add(new IdPAttributePrincipal(attr));
 
    request.setAttribute(ExternalAuthentication.SUBJECT_KEY,new Subject(false, principals, Collections.EMPTY_SET, Collections.EMPTY_SET));
 
    ExternalAuthentication.finishExternalAuthentication(key, request, response);
 
} catch (final ExternalAuthenticationException e) {
    throw new ServletException("Error processing external authentication request", e);
}
%>


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