Regarding authentication in shibboleth
Kevin P. Foote
kpfoote at iup.edu
Thu Aug 11 12:23:27 BST 2011
The apache require statement does not have access to anything called
"organizationalUnit".
You can either change your require statement to read
"require ou computer"
Or you can map the incomming attribute ou to your friendly name
"organizationalUnit" on the SP side using the attribute-map file
with something like below and described on the wiki [1].
<Attribute name="urn:oid:2.5.4.11" id="NAME-I-WANT-APACHE-TO-SEE"/>
[1]
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAddAttribute
------
thanks
kevin.foote
On Thu, 11 Aug 2011, Naveen Davis wrote:
-> Hi Kevin,
->
-> I didn't get your question. I have copy pasted the contents of my
-> attribute-map file for your reference.
->
-> Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map"
-> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
->
-> <!-- First some useful eduPerson attributes that many sites might
-> use. -->
->
-> <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>
->
-> <Attribute
-> name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"
-> id="affiliation">
-> <AttributeDecoder xsi:type="ScopedAttributeDecoder"
-> caseSensitive="false"/>
-> </Attribute>
-> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" id="affiliation">
-> <AttributeDecoder xsi:type="ScopedAttributeDecoder"
-> caseSensitive="false"/>
-> </Attribute>
->
-> <Attribute name="urn:mace:dir:attribute-def:eduPersonAffiliation"
-> id="unscoped-affiliation">
-> <AttributeDecoder xsi:type="StringAttributeDecoder"
-> caseSensitive="false"/>
-> </Attribute>
-> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
-> id="unscoped-affiliation">
-> <AttributeDecoder xsi:type="StringAttributeDecoder"
-> caseSensitive="false"/>
-> </Attribute>
->
-> <Attribute name="urn:mace:dir:attribute-def:eduPersonEntitlement"
-> id="entitlement"/>
-> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7"
-> id="entitlement"/>
->
-> <!-- A persistent id attribute that supports personalized anonymous
-> access. -->
->
-> <!-- First, the deprecated/incorrect version, decoded as a scoped
-> string: -->
-> <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
-> id="targeted-id">
-> <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
-> <!-- <AttributeDecoder
-> xsi:type="NameIDFromScopedAttributeDecoder" formatter="$NameQualifier!
-> $SPNameQualifier!$Name" defaultQualifiers="true"/> -->
-> </Attribute>
->
-> <!-- Second, an alternate decoder that will decode the incorrect
-> form into the newer form. -->
-> <!--
-> <Attribute name="urn:mace:dir:attribute-def:eduPersonTargetedID"
-> id="persistent-id">
-> <AttributeDecoder xsi:type="NameIDFromScopedAttributeDecoder"
-> formatter="$NameQualifier!$SPNameQualifier!$Name"
-> defaultQualifiers="true"/>
-> </Attribute>
-> -->
->
-> <!-- Third, the new version (note the OID-style name): -->
-> <Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"
-> id="persistent-id">
-> <AttributeDecoder xsi:type="NameIDAttributeDecoder"
-> formatter="$NameQualifier!$SPNameQualifier!$Name"
-> defaultQualifiers="true"/>
-> </Attribute>
->
-> <!-- Fourth, the SAML 2.0 NameID Format: -->
-> <Attribute
-> name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
-> id="persistent-id">
-> <AttributeDecoder xsi:type="NameIDAttributeDecoder"
-> formatter="$NameQualifier!$SPNameQualifier!$Name"
-> defaultQualifiers="true"/>
-> </Attribute>
->
->
-> <!--Examples of LDAP-based attributes, uncomment to use these... -->
->
->
-> <Attribute name="urn:oid:2.5.4.3" id="cn"/>
-> <Attribute name="urn:oid:2.5.4.4" id="sn"/>
-> <Attribute name="urn:oid:2.5.4.11" id="ou"/>
->
->
-> </Attributes>
->
->
-> BR,
-> Naveen
->
-> On Thu, 2011-08-11 at 07:02 -0400, Kevin P. Foote wrote:
-> > Then is the IdP released attribute "ou" mapped in the attribute-map file to
-> > what apache expects "organizationalUnit"?
-> >
-> > ------
-> > thanks
-> > kevin.foote
-> >
-> > On Thu, 11 Aug 2011, Naveen Davis wrote:
-> >
-> > -> Hi Kevin,
-> > ->
-> > -> Yes my idp is releasing the attribute information as required.
-> > -> The Shibboleth.sso/Session handler gives the following output
-> > ->
-> > -> Miscellaneous
-> > ->
-> > -> Identity Provider: https://idp1.example.org/idp/shibboleth
-> > -> SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
-> > -> Authentication Time: 2011-08-11T10:38:17.413Z
-> > -> Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
-> > -> Authentication Context Decl: (none)
-> > -> Session Expiration (barring inactivity): 466 minute(s)
-> > ->
-> > -> Attributes
-> > -> cn: Staff
-> > -> ou: computer
-> > -> sn: Test
-> > ->
-> > -> BR,
-> > -> Naveen
-> > ->
-> > -> On Thu, 2011-08-11 at 06:46 -0400, Kevin P. Foote wrote:
-> > -> > Naveen,
-> > -> >
-> > -> > Is your IdP releasing the attribute "organizationalUnit" to your SP?
-> > -> >
-> > -> > Your apache Location block is requiring a value of "computer" to be present
-> > -> > in that attribute for access to your location.
-> > -> >
-> > -> > A simper test would be to use require valid-user for initial testing.
-> > -> > Then hit the Shibboleth.sso/Session handler and verify that all your
-> > -> > attributes are being passed to the SP.
-> > -> >
-> > -> > ------
-> > -> > thanks
-> > -> > kevin.foote
-> > -> >
-> > -> > On Thu, 11 Aug 2011, Naveen Davis wrote:
-> > -> >
-> > -> > -> Hi,
-> > -> > ->
-> > -> > -> I am testing out authentication and access control in shibboleth by
-> > -> > -> modifying shib.conf file. I have created a new location called "staff"
-> > -> > -> which should only be accessed by the "computer" organizational unit.
-> > -> > -> Given below is my configuration in shib.conf file.
-> > -> > ->
-> > -> > -> #
-> > -> > -> # Configure the module for content.
-> > -> > -> #
-> > -> > -> # You MUST enable AuthType shibboleth for the module to process
-> > -> > -> # any requests, and there MUST be a require command as well. To
-> > -> > -> # enable Shibboleth but not specify any session/access requirements
-> > -> > -> # use "require shibboleth".
-> > -> > -> #
-> > -> > -> <Location /secure>
-> > -> > -> AuthType shibboleth
-> > -> > -> ShibRequestSetting requireSession 1
-> > -> > -> require valid-user
-> > -> > -> </Location>
-> > -> > ->
-> > -> > -> <Location /staff>
-> > -> > -> AuthType shibboleth
-> > -> > -> ShibRequestSetting requireSession 1
-> > -> > -> require organizationalUnit computer
-> > -> > -> </Location>
-> > -> > ->
-> > -> > ->
-> > -> > -> I have created a test user "staff" with organizationalUnitName
-> > -> > -> "computer" in the LDAP.But when trying to access this location I am
-> > -> > -> getting the following error.
-> > -> > ->
-> > -> > -> Forbidden
-> > -> > -> You don't have permission to access /staff/ on this server.
-> > -> > ->
-> > -> > ->
-> > -> > -> ________________________________________________________________________
-> > -> > -> Apache/2.2.3 (CentOS) Server at sp2.example.org Port 443
-> > -> > ->
-> > -> > -> Could anyone provide me some insight in to what I am doing wrong here.
-> > -> > ->
-> > -> > -> BR,
-> > -> > -> Naveen
-> > -> > ->
-> > -> > -> --
-> > -> > -> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-> > -> > ->
-> > -> > --
-> > -> > To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-> > ->
-> > ->
-> > -> --
-> > -> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-> > ->
-> > --
-> > To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
->
->
-> --
-> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
->
More information about the users
mailing list