Getting the authenticated user name

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

Getting the authenticated user name

istvangonzales
 
Sorry but I'm just not getting this part. How do I get the authenticated username (in my case, ip-user) to get from the IDP to the service provider and into the application? Preferably using some standard SAML attributes (not eduPerson* ones)?
 
Information is released through attributes, and attributes are defined by the IdP using an AttributeDefinition, but just how does the AttributeDefinition say "the data to be released is the name of the authenticated user".
 
Is there also a standard name for the attribute that represents the authenticated user name, or do I just come up with whatever name? What's the difference between persistent-id and targeted-id?
 
How far from the default configuration do I need to go in order for the authenticated user name to be available in my application?
 
Reply | Threaded
Open this post in threaded view
|

Re: Getting the authenticated user name

istvangonzales
 
 
It suggests using this:
<resolver:AttributeDefinition id="principal" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad"> 
    <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" 
        nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" /> 
</resolver:AttributeDefinition> 

which causes this to be sent over the wire by the IdP:
 
(1) <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">rjm</saml:NameID> 
 
 
So the id attribute is used internally by the IDP in case the attribute needs to be released explicitly in which case the attribute will need to be referenced. The type, in this case PrincipalName, tells the IdP that the value will be assigned from the authenticated user. xmlns - dunno, probably a namespace for the type. The attribute encoder controls how the attribute is represented over the wire.
 
Of course a lot of questions are still unanswered on the SP side, but there's also a major question on the IdP side: which part of line (1) is the attribute name? Is it NameID? If yes, where in the AttributeDefinition element did I specify that name? Is it in the attribute encoder's type? It sounds silly to have the attribute name be determined by the choice of encoder. Or is the nice URN that ends with "unspecified" the actual name? That also sounds silly, as it's really called Format.
 
So I looked a bit on the SP side to see if anything gets suggested. The hope is that REMOTE_USER in <ApplicationDefaults REMOTE_USER="eppn transient-id persistent-id"/> identifies a list of attributes that can represent the authenticated user and consequently that may have been sent by the IdP using a line like (1). These are just ids resolved using the SP's attribute-map.xml file. But the actual attribute names represented by these IDs are themselves URNs like urn:mace:dir:attribute-def:eduPersonTargetedID. Presumably if the IdP were to release the authenticated user name as one of these attributes everything would start happening - the SP would find it and publish it in the REMOTE_USER HTTP header.
 
Then, where do I define that name? Is it really in the attribute encoder?
 
 
On Sun, Jun 20, 2010 at 11:06 AM, Istvan Gonzales <[hidden email]> wrote:
 
Sorry but I'm just not getting this part. How do I get the authenticated username (in my case, ip-user) to get from the IDP to the service provider and into the application? Preferably using some standard SAML attributes (not eduPerson* ones)?
 
Information is released through attributes, and attributes are defined by the IdP using an AttributeDefinition, but just how does the AttributeDefinition say "the data to be released is the name of the authenticated user".
 
Is there also a standard name for the attribute that represents the authenticated user name, or do I just come up with whatever name? What's the difference between persistent-id and targeted-id?
 
How far from the default configuration do I need to go in order for the authenticated user name to be available in my application?
 

Reply | Threaded
Open this post in threaded view
|

Re: Getting the authenticated user name

Peter Schober
In reply to this post by istvangonzales
* Istvan Gonzales <[hidden email]> [2010-06-20 17:08]:
> Sorry but I'm just not getting this part. How do I get the authenticated
> username (in my case, ip-user) to get from the IDP to the service provider
> and into the application? Preferably using some standard SAML attributes
> (not eduPerson* ones)?

Does this help?
https://spaces.internet2.edu/display/SHIB2/NativeSPAttributeAccess
-peter
Reply | Threaded
Open this post in threaded view
|

Re: Getting the authenticated user name

Peter Schober
In reply to this post by istvangonzales
* Istvan Gonzales <[hidden email]> [2010-06-20 17:08]:
> Is there also a standard name for the attribute that represents the
> authenticated user name, or do I just come up with whatever name?

There is no universal standard and different applications expect
specific different types of identifiers there.
The closest thing in SAML is the NameID (which is not an attribute).
https://spaces.internet2.edu/display/SHIB2/NameIDAttributes

You've also already noticed that the SP has a precedence list of
attribute ids (set in the attribute-map.xml from the attribute's
actual name), so this already answers your question about /the/ one
attribute (there isn't one).

> What's the difference between persistent-id and targeted-id?

The former is a SAML-standardized concept, the latter is not.
Practically the difference is now mostly historic, I suppose.
The latter (as used inside the SP's attribute map) has been defined
by Internet2/I2MI/MACE-Dir for use with SAML1.x.
With SAML2 they could be seen as refering mostly to the same thing.
(Scott will certaily correct me on several accounts).

https://spaces.internet2.edu/display/SHIB2/IdPPersistentNameIdentifier

Nowadays, if you want or need to support a targeted identifier (i.e.,
one that is different at each relying party/service provider for the
same principal, from the same issuer) using (conceptually)
eduPersonTargetedId as a NameID inside the authentication assertion's
subject is preferred, at least in higher education and resaerch
communities. See
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200804.pdf

* Istvan Gonzales <[hidden email]> [2010-06-20 17:39]:
> Then, where do I define that name? Is it really in the attribute
> encoder?

Yes. The AttributeEncoder/@name is the attributes name. Which is a
URI, often urn with the attribute's oid (as assigned by IANA), or url.
You'll see these attribute names featured prominently in both the
attribute-resolver.xml on the IdP and in the SP's attribute-map.xml
-peter
Reply | Threaded
Open this post in threaded view
|

RE: Getting the authenticated user name

Cantor, Scott E.
In reply to this post by istvangonzales
> Sorry but I'm just not getting this part. How do I get the authenticated
> username (in my case, ip-user) to get from the IDP to the service provider
> and into the application? Preferably using some standard SAML attributes
> (not eduPerson* ones)?

There are no standard SAML attributes, and the only formats for the SAML
NameID with actual semantics are transient and persistent.

And without defining the semantics required of a particular identifier by
the RP, you can't map effectively from a local domain to an identifier that
meets its requirements effectively.

Generally speaking if you're not using transient or persistent, the best
course is to define an attribute with specific semantics and then populate
it as needed.

This material may be useful.
https://spaces.internet2.edu/display/SHIB2/NameIDAttributes

> Information is released through attributes, and attributes are defined by
> the IdP using an AttributeDefinition, but just how does the
> AttributeDefinition say "the data to be released is the name of the
> authenticated user".

I believe you found some of that.

> How far from the default configuration do I need to go in order for the
> authenticated user name to be available in my application?

If you're not using eduPersonPrincipalName or a SAML persistent ID (which is
opaque), a significant amount on both ends. This is not because we think
eduPerson (which is not education specific) is the only way to do it, but
because it's the only well-defined example to use.

-- Scott



Reply | Threaded
Open this post in threaded view
|

Re: Getting the authenticated user name

istvangonzales
 
So is there any difference between transient, persistent, unspecified if I don't change any configuration? If there's a difference (in the persistence of the attribute), there would have to be some built-in timeout somewhere already configured.
 
I went ahead and created a custom attribute name to the IdP linked with the authenticated username.
    <resolver:AttributeDefinition id="mycompany-username" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
        <resolver:AttributeEncoder
            xsi:type="SAML2StringNameID"
            xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="https://mycompany.com/username"
            nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />
    </resolver:AttributeDefinition>
The attribute filter policy on the IdP side allows this attribute to be sent:
  <!--  Release the MyCompany username to anyone -->
  <AttributeFilterPolicy id="releaseMyCompanyUsernameToAnyone">
    <PolicyRequirementRule xsi:type="basic:ANY" />
    <AttributeRule attributeID="mycompany-username">
      <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
  </AttributeFilterPolicy>
On the SP side, I have an attribute map for this baby as follows:
    <Attribute name="https://mycompany.com/username" id="mycompany-username">
        <AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/>
    </Attribute>
 
And of course an attibute policy that allows this name:
        ...
        <!-- Catch-all that passes everything else through unmolested. -->
        <afp:AttributeRule attributeID="*">
            <afp:PermitValueRule xsi:type="ANY"/>
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>
Yet, the SP's transaction.log list fails to bring it up:
2010-06-20 14:59:54 INFO Shibboleth-TRANSACTION [1] insert: Cached the following attributes with session (ID: _201b5e8b54ae66fa2666e93aa2ce2ade) for (applicationId: default) {
2010-06-20 14:59:54 INFO Shibboleth-TRANSACTION [1] insert: }
I must be missing something with regard to encoding, isn't it?

 
On Sun, Jun 20, 2010 at 1:01 PM, Scott Cantor <[hidden email]> wrote:
> Sorry but I'm just not getting this part. How do I get the authenticated
> username (in my case, ip-user) to get from the IDP to the service provider
> and into the application? Preferably using some standard SAML attributes
> (not eduPerson* ones)?

There are no standard SAML attributes, and the only formats for the SAML
NameID with actual semantics are transient and persistent.

And without defining the semantics required of a particular identifier by
the RP, you can't map effectively from a local domain to an identifier that
meets its requirements effectively.

Generally speaking if you're not using transient or persistent, the best
course is to define an attribute with specific semantics and then populate
it as needed.

This material may be useful.
> Information is released through attributes, and attributes are defined by
> the IdP using an AttributeDefinition, but just how does the
> AttributeDefinition say "the data to be released is the name of the
> authenticated user".

I believe you found some of that.

> How far from the default configuration do I need to go in order for the
> authenticated user name to be available in my application?

If you're not using eduPersonPrincipalName or a SAML persistent ID (which is
opaque), a significant amount on both ends. This is not because we think
eduPerson (which is not education specific) is the only way to do it, but
because it's the only well-defined example to use.

-- Scott




Reply | Threaded
Open this post in threaded view
|

RE: Getting the authenticated user name

Cantor, Scott E.
> So is there any difference between transient, persistent, unspecified if I
> don't change any configuration? If there's a difference (in the
persistence
> of the attribute), there would have to be some built-in timeout somewhere
> already configured.

I don't understand the question. Those are completely different ideas,
constructs, content, etc. You can read the relevant SAML specifications if
you're confused about the meaning of the formats.

> I went ahead and created a custom attribute name to the IdP linked with
the
> authenticated username.

No, you encoded it as a NameID with a meaningless Format (unspecified).
That's always the wrong approach. If you need a custom Format, define one,
but don't use unspecified.

> On the SP side, I have an attribute map for this baby as follows:
>     <Attribute name="https://mycompany.com/username" id="mycompany-
> username">

That's incorrect. You're sending the data as a NameID, therefore the "name"
in the rule has to match the Format attribute in the NameID.

> I must be missing something with regard to encoding, isn't it?

You're confusing an Attribute with a NameID and putting the wrong thing into
the extraction rule.

-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: Getting the authenticated user name

istvangonzales
 
About transient/persistent, I was wondering whether my choice of one over the other actually affects the length of time that IdP or SP caches the attribute which uses it.
 
I don't need a custom format for the NameID, good point. In fact, looking at some sample attribute encoders in attribute-resolver.xml, many don't specify a nameFormat. I'm removing it. I really only need a string (and maybe later I'll play with scoped string). SAML2StringNameID looks like it's good enough.
Now for the SP side, if https://mycompany.com/username isn't the name of the attribute, then two questions arise. First, where in the SP do I use https://mycompany.com/username, the name I assigned to the attribute on the IdP side, and second, what name do I give the attribute on the SP side if I choose not to specify a format on the IdP side, a scenario which the IdP seems to allow, judging by the samples.
 
And finally, looking at eduPersonPrincipalName as a baseline, it's defined this way in the IdP:
    <resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
        scope="mlsli.com" sourceAttributeID="uid">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:mace:dir:attribute-def:eduPersonPrincipalName" />
        <resolver:AttributeEncoder xsi:type="SAML2ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />
    </resolver:AttributeDefinition>
and this way in the SP:
    <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    </Attribute>
    <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    </Attribute>
(good to know we can reuse the ID)
 
which seems to indicate that the SP must use AttributeDefinition/AttributeEncoder/@name as Attribute/@name.
 
 
On Sun, Jun 20, 2010 at 3:20 PM, Scott Cantor <[hidden email]> wrote:
> So is there any difference between transient, persistent, unspecified if I
> don't change any configuration? If there's a difference (in the
persistence
> of the attribute), there would have to be some built-in timeout somewhere
> already configured.

I don't understand the question. Those are completely different ideas,
constructs, content, etc. You can read the relevant SAML specifications if
you're confused about the meaning of the formats.

> I went ahead and created a custom attribute name to the IdP linked with
the
> authenticated username.

No, you encoded it as a NameID with a meaningless Format (unspecified).
That's always the wrong approach. If you need a custom Format, define one,
but don't use unspecified.

> On the SP side, I have an attribute map for this baby as follows:
>     <Attribute name="https://mycompany.com/username" id="mycompany-
> username">

That's incorrect. You're sending the data as a NameID, therefore the "name"
in the rule has to match the Format attribute in the NameID.

> I must be missing something with regard to encoding, isn't it?

You're confusing an Attribute with a NameID and putting the wrong thing into
the extraction rule.

-- Scott



Reply | Threaded
Open this post in threaded view
|

Re: Getting the authenticated user name

istvangonzales
 
OK nevermind, my brains caught up with me eventually.
 
The difference is that eduPersonPrincipalName isn't exposed as a NameID.
 
Since I expose as a NameID, [hidden email] is meaningless, as there can be only one NameID (assumption) (perhaps encoded multiple times) in the IdP's response.
I still don't get how the SP side attribute is marked as a NameID. Probably via its attribute decoder. Now it makes more sense.
 
Maybe I'll just use a SAML2 string or maybe a scoped string.
 

 
On Sun, Jun 20, 2010 at 3:40 PM, Istvan Gonzales <[hidden email]> wrote:
 
About transient/persistent, I was wondering whether my choice of one over the other actually affects the length of time that IdP or SP caches the attribute which uses it.
 
I don't need a custom format for the NameID, good point. In fact, looking at some sample attribute encoders in attribute-resolver.xml, many don't specify a nameFormat. I'm removing it. I really only need a string (and maybe later I'll play with scoped string). SAML2StringNameID looks like it's good enough.
Now for the SP side, if https://mycompany.com/username isn't the name of the attribute, then two questions arise. First, where in the SP do I use https://mycompany.com/username, the name I assigned to the attribute on the IdP side, and second, what name do I give the attribute on the SP side if I choose not to specify a format on the IdP side, a scenario which the IdP seems to allow, judging by the samples.
 
And finally, looking at eduPersonPrincipalName as a baseline, it's defined this way in the IdP:
    <resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
        scope="mlsli.com" sourceAttributeID="uid">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:mace:dir:attribute-def:eduPersonPrincipalName" />
        <resolver:AttributeEncoder xsi:type="SAML2ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />
    </resolver:AttributeDefinition>
and this way in the SP:
    <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    </Attribute>
    <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    </Attribute>
(good to know we can reuse the ID)
 
which seems to indicate that the SP must use AttributeDefinition/AttributeEncoder/@name as Attribute/@name.
 
 
On Sun, Jun 20, 2010 at 3:20 PM, Scott Cantor <[hidden email]> wrote:
> So is there any difference between transient, persistent, unspecified if I
> don't change any configuration? If there's a difference (in the
persistence
> of the attribute), there would have to be some built-in timeout somewhere
> already configured.

I don't understand the question. Those are completely different ideas,
constructs, content, etc. You can read the relevant SAML specifications if
you're confused about the meaning of the formats.

> I went ahead and created a custom attribute name to the IdP linked with
the
> authenticated username.

No, you encoded it as a NameID with a meaningless Format (unspecified).
That's always the wrong approach. If you need a custom Format, define one,
but don't use unspecified.

> On the SP side, I have an attribute map for this baby as follows:
>     <Attribute name="https://mycompany.com/username" id="mycompany-
> username">

That's incorrect. You're sending the data as a NameID, therefore the "name"
in the rule has to match the Format attribute in the NameID.

> I must be missing something with regard to encoding, isn't it?

You're confusing an Attribute with a NameID and putting the wrong thing into
the extraction rule.

-- Scott




Reply | Threaded
Open this post in threaded view
|

Re: Getting the authenticated user name

istvangonzales
 
I got it working as a SAML2 string encoded attribute, after the model of some of the existing attributes. Not as cool as sending it as a NameID, which beats string attributes with custom names, but it works.
Thanks much for the insight! :)

idp/conf/attribute-resolver.xml:
    <resolver:AttributeDefinition id="mycompany-username-idp" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">
      <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        name="https://mycompany.com/username" friendlyName="mycompany-username" />
    </resolver:AttributeDefinition>
idp/conf/attribute-filter.xml:
  <!--  Release the MyCompany username to anyone -->
  <AttributeFilterPolicy id="releaseMyCompanyUsernameToAnyone">
    <PolicyRequirementRule xsi:type="basic:ANY" />
    <AttributeRule attributeID="mycompany-username-idp">
      <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>
  </AttributeFilterPolicy>
sp/etc/shibboleth/attribute-map.xml:
    <Attribute name="https://mycompany.com/username" id="mycompany-username-sp">
      <AttributeDecoder xsi:type="StringAttributeDecoder" caseSensitive="true"/>
    </Attribute>
sp/etc/shibboleth/attribute-map.xml:
    <ApplicationDefaults REMOTE_USER="mycompany-username-sp ..."
 
I used different IDs on the IdP and SP side to point out the reach of these.
 
On Sun, Jun 20, 2010 at 3:45 PM, Istvan Gonzales <[hidden email]> wrote:
 
OK nevermind, my brains caught up with me eventually.
 
The difference is that eduPersonPrincipalName isn't exposed as a NameID.
 
Since I expose as a NameID, [hidden email] is meaningless, as there can be only one NameID (assumption) (perhaps encoded multiple times) in the IdP's response.
I still don't get how the SP side attribute is marked as a NameID. Probably via its attribute decoder. Now it makes more sense.
 
Maybe I'll just use a SAML2 string or maybe a scoped string.
 

 
On Sun, Jun 20, 2010 at 3:40 PM, Istvan Gonzales <[hidden email]> wrote:
 
About transient/persistent, I was wondering whether my choice of one over the other actually affects the length of time that IdP or SP caches the attribute which uses it.
 
I don't need a custom format for the NameID, good point. In fact, looking at some sample attribute encoders in attribute-resolver.xml, many don't specify a nameFormat. I'm removing it. I really only need a string (and maybe later I'll play with scoped string). SAML2StringNameID looks like it's good enough.
Now for the SP side, if https://mycompany.com/username isn't the name of the attribute, then two questions arise. First, where in the SP do I use https://mycompany.com/username, the name I assigned to the attribute on the IdP side, and second, what name do I give the attribute on the SP side if I choose not to specify a format on the IdP side, a scenario which the IdP seems to allow, judging by the samples.
 
And finally, looking at eduPersonPrincipalName as a baseline, it's defined this way in the IdP:
    <resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
        scope="mlsli.com" sourceAttributeID="uid">
        <resolver:Dependency ref="myLDAP" />
        <resolver:AttributeEncoder xsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:mace:dir:attribute-def:eduPersonPrincipalName" />
        <resolver:AttributeEncoder xsi:type="SAML2ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
            name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />
    </resolver:AttributeDefinition>
and this way in the SP:
    <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    </Attribute>
    <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" id="eppn">
        <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
    </Attribute>
(good to know we can reuse the ID)
 
which seems to indicate that the SP must use AttributeDefinition/AttributeEncoder/@name as Attribute/@name.
 
 
On Sun, Jun 20, 2010 at 3:20 PM, Scott Cantor <[hidden email]> wrote:
> So is there any difference between transient, persistent, unspecified if I
> don't change any configuration? If there's a difference (in the
persistence
> of the attribute), there would have to be some built-in timeout somewhere
> already configured.

I don't understand the question. Those are completely different ideas,
constructs, content, etc. You can read the relevant SAML specifications if
you're confused about the meaning of the formats.

> I went ahead and created a custom attribute name to the IdP linked with
the
> authenticated username.

No, you encoded it as a NameID with a meaningless Format (unspecified).
That's always the wrong approach. If you need a custom Format, define one,
but don't use unspecified.

> On the SP side, I have an attribute map for this baby as follows:
>     <Attribute name="https://mycompany.com/username" id="mycompany-
> username">

That's incorrect. You're sending the data as a NameID, therefore the "name"
in the rule has to match the Format attribute in the NameID.

> I must be missing something with regard to encoding, isn't it?

You're confusing an Attribute with a NameID and putting the wrong thing into
the extraction rule.

-- Scott





Reply | Threaded
Open this post in threaded view
|

RE: Getting the authenticated user name

Cantor, Scott E.
In reply to this post by istvangonzales
> About transient/persistent, I was wondering whether my choice of one over
> the other actually affects the length of time that IdP or SP caches the
> attribute which uses it.

The SP doesn't cache things across sessions. The issue is what the
application can expect and do with the information.
 
> Now for the SP side, if https://mycompany.com/username isn't the name of
the
> attribute, then two questions arise.

You didn't have an *Attribute*, you were sending a NameID.

> First, where in the SP do I use
> https://mycompany.com/username, the name I assigned to the attribute on
the
> IdP side,

If you're turning the attribute into a NameID, the name is unused. It
doesn't appear on the wire and therefore has no relevance to the SP. For a
NameID, only the Format matters, and the Format is keyed by the "name"
property in an extraction rule. All of this is documented.

> and second, what name do I give the attribute on the SP side if I
> choose not to specify a format on the IdP side, a scenario which the IdP
> seems to allow, judging by the samples.

The absence of a nameFormat for a SAML attribtue results in a NameFormat
constant of "...:uri", which is the default assumption of both the IdP and
SP when manipulating them. None of that is applicable to a NameID.

> which seems to indicate that the SP must use
> AttributeDefinition/AttributeEncoder/@name as Attribute/@name.

When it's *not* a NameID, yes.

-- Scott



Reply | Threaded
Open this post in threaded view
|

Attribute release problem

Jc Polanycia
In reply to this post by Cantor, Scott E.
Hello,
        I've just installed a version 2.1.5 IdP(on Solaris in a tomcat 6.0 server that is fronted by Apache 2.2) and a version 2.3.1 SP(on RHEL5 with the stock Apache) and I'm having a problem getting the attributes to the SP.  When I connect to a Shib protected resource on the SP I am redirected to the login page on the IdP.  I am able to successfully login and I'm redirected back to the protected resource and I can access the page.  However, I get an error in the shibd.log on the SP

2010-07-07 15:25:42 WARN Shibboleth.AttributeResolver.Query [2]: response from attribute authority was empty

I checked the environment variables within Apache and I do get some variables such as Shib-Application-ID, but no attributes.

I went back to the IdP and used the aacli.sh tool with the identical requestor and issuer parameters and it does return all of the attributes I have configured and released via attribute-filter.xml and attribute-resolver.xml on the IdP.

There are no other errors in the shibd.log or transaction.log on the SP nor are any errors given in the idp logs.

Does anyone have any ideas on what might be happening or suggestions on how to further troubleshoot this?

Thanks!

-jc
Reply | Threaded
Open this post in threaded view
|

Re: Attribute release problem

Nate Klingenstein
Jc,

>I went back to the IdP and used the aacli.sh tool with the identical requestor and issuer parameters and it does return all of the attributes I have configured and released via attribute-filter.xml and attribute-resolver.xml on the IdP.

That, in concert with your other symptoms, would indicate that your IdP is configured well, but this transaction is not sending attributes through the front-channel.  That's probably because you're using SAML 1.1, which in turn, because both your providers are Shibboleth 2.x, is probably because either your metadata is wrong or the wrong authentication request format is being used.

First, I'd try to determine why it's not using SAML 2.0.  Check the outbound request first to see if it's carrying a SAMLRequest=base64goo parameter, or a providerId&SHIRE&target set of parameters.  If it's the latter(3 parameters), you need to check the active SessionInitiator to ensure it will use SAML 2.0 if available, and then the IdP's metadata to make sure it's advertising SAML 2.0 support.  If it's the former, then you need to check the SP's metadata to make sure it's advertising SAML 2.0 support too.

Secondly, the empty attribute query is because, upon receiving no attributes in the initial response, the SP is automagically dispatching a request for the attributes to you on 8443.  Either you haven't setup port 8443, or you have a box in the network somewhere that is eating the query.  Neither is a huge deal if you're using SAML 2.0 for normal use cases, so I'd try to figure out why it's failing back to SAML 1.1 first using the debugging steps I enumerated earlier.

Ready to help if you need further assistance,
Nate.
Reply | Threaded
Open this post in threaded view
|

RE: Attribute release problem

Cantor, Scott E.
> Secondly, the empty attribute query is because, upon receiving no attributes
> in the initial response, the SP is automagically dispatching a request for
> the attributes to you on 8443.  Either you haven't setup port 8443, or you
> have a box in the network somewhere that is eating the query.

No, "empty response" means it's listening and responding properly, just not releasing any data.

The IdP logs are what you have to look at.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Attribute release problem

Jc Polanycia
I looked through the idp logs after checking the metadata to verify that they are configured to use SAML 2.0.

Note that the Dates, IPs, Principals and hostnames have been replaced.

idp-access.log shows this:

DATE|SPs_IP|IDPs_IP:443|/profile/SAML2/Redirect/SSO|
DATE|SPs_IP|IDPs_IP:8443|/profile/SAML2/SOAP/AttributeQuery

which looks like the Attribute query is making it to the SOAP port on the IDP(ie. it is not being intercepted).

idp-audit.log shows this:

DATE|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_19002ff82cd
5f413e5ee62abe27a39e6|SPs_ID|urn:mace:shibboleth:2.0:profiles:saml2:sso|IDPs_ID|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_ff99b025927a13ff771b26a23b868324|PRINCIPAL|urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport||||

DATE|urn:oasis:names:tc:SAML:2.0:bindings:SOAP|_81a05be62fe6142c7830c220ce5b9e37|SPs_ID|urn:mace:shibboleth:2.0:profiles:saml2:query:attribute|IDPs_ID|urn:oasis:names:tc:SAML:2.0:bindings:SOAP|_eef3e32b804ffef496092f0e01975099|PRINCIPAL||transientId,|||


Am I reading that right that the only attribute being returned is transientId?

It strikes me as odd that aacli.sh will return the attributes.  I'll try turning up the logging to debug and see if anything else is reported.  Is there a way to narrow that down to just the attribute query/release?

-jc


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Scott Cantor
Sent: 07 July, 2010 4:13 PM
To: [hidden email]
Subject: RE: [Shib-Users] Attribute release problem

> Secondly, the empty attribute query is because, upon receiving no attributes
> in the initial response, the SP is automagically dispatching a request for
> the attributes to you on 8443.  Either you haven't setup port 8443, or you
> have a box in the network somewhere that is eating the query.

No, "empty response" means it's listening and responding properly, just not releasing any data.

The IdP logs are what you have to look at.

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Attribute release problem

Cantor, Scott E.
> I looked through the idp logs after checking the metadata to verify that
> they are configured to use SAML 2.0.

Then there's no need for a query and you shouldn't be including an AA endpoint in your metadata for SAML 2.0 usage. It's just a waste of time.

> idp-access.log shows this:

Wrong log.

-- Scott