Access Denied

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

Access Denied

tolock

I’m in the process of moving from V2 Shibboleth to V3. I am working through changes in my configuration files.

One of my SP is giving an Access is denied message.

The old syntax is using 2 of the deprecated values SAML1StringNameIdentifier and SAML2StringNameID.

I have placed what I thought might would work in the saml-nameid.xml file but I’m still receiving the access is denied error message.

The logs from the SP

Unable to populate standard claim loginId from mapped claim name ….

Below are my conf files from both V3 and V2.

 

 

Attribute-Resolver.xml

V3

 

<resolver:AttributeDefinition id="Login" xsi:type="ad:Simple"

         sourceAttributeID="sAMAccountName">

        <resolver:Dependency ref="myLDAP" />

 

 

Saml-nameid.xml

 

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"

            p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:transient"

            p:attributeSourceIds="#{ {'Login'} }" >

      </bean>

 

Saml-nameid.properties

 

# Default NameID Formats to use when nothing else is called for.

# Don't change these just to change the Format used for a single SP!

idp.nameid.saml2.default = urn:oasis:names:tc:SAML:2.0:nameid-format:transient

idp.nameid.saml1.default = urn:mace:shibboleth:1.0:nameIdentifier

 

V2

 

<resolver:AttributeDefinition id="Login" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"

        sourceAttributeID="sAMAccountName">

        <resolver:Dependency ref="myLDAP" />

 

        <resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"

            nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:transient" />

 

        <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"

                nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />

 

    </resolver:AttributeDefinition>

 

 

 

Attribute-Filter.xml

 

<AttributeFilterPolicy id="releaseLoginToSAASIT">

        <PolicyRequirementRule xsi:type="Requester" value="https://uncp.saasit.com/" />

 

        <AttributeRule attributeID="Login">

        <PermitValueRule xsi:type="ANY" />

        </AttributeRule>

        </AttributeFilterPolicy>

 

 

 

Relying-Party.xml

V3

<bean parent="RelyingPartyByName" c:relyingPartyIds="https://uncp.saasit.com/">

        <property name="profileConfigurations">

            <list>

            <!-- Your refs or beans here. -->

                <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1:1:nameid-format:unspecified" p:encryptAssertions="false" p:encryptNameIDs="false" p:signAssertions="true" p:signResponses="false"/>

             </list>

        </property>

    </bean>

 

V2

<rp:RelyingParty id="https://uncp.saasit.com/"

       provider="https://idp.uncp.edu/idp/shibboleth"

       defaultSigningCredentialRef="IdPCredential">

       <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" assertionProxyCount="0" signResponses="never" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never" />

        </rp:RelyingParty>

 

 

 

 

 

Tabitha O. Locklear

MS Information Technology

Operations & Systems Analyst

Division of Information Technology

University of North Carolina at Pembroke

[hidden email]

Office : 910-775-4039

Fax : 910-521-6649

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Tabitha O. Locklear
MS Information Technology
Operations & Systems Analyst
Division of Information Technology
University of North Carolina at Pembroke
tabithao.locklear@uncp.edu
Reply | Threaded
Open this post in threaded view
|

Re: Access Denied

Peter Schober
* Tabitha O. Locklear <[hidden email]> [2018-07-27 15:35]:

> Attribute-Resolver.xml
> V3
>
> <resolver:AttributeDefinition id="Login" xsi:type="ad:Simple"
>          sourceAttributeID="sAMAccountName">
>         <resolver:Dependency ref="myLDAP" />
>
>
> Saml-nameid.xml
>
> <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
>             p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:transient"
>             p:attributeSourceIds="#{ {'Login'} }" >
>       </bean>

sAMAccountName does not have "transient semantics", as required for
transient NameIDs by the SAML specification. So while your old config
also had that it's a violation of the SAML spec -- are you positive
the SP requires the transient NameID format? If not use any other
NameID format, including sAMAccountName's formal name as p:format
above.

> Relying-Party.xml
> V3
> <bean parent="RelyingPartyByName" c:relyingPartyIds="https://uncp.saasit.com/">
>         <property name="profileConfigurations">
>             <list>
>             <!-- Your refs or beans here. -->
>                 <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1:1:nameid-format:unspecified" p:encryptAssertions="false" p:encryptNameIDs="false" p:signAssertions="true" p:signResponses="false"/>
>              </list>
>         </property>
>     </bean>

First you're stuffing sAMAccountName into a transient NameID, but then
you're setting the preferred NameID format for that SP to
"unspecified".  That doesn't make sense to me.

-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: Access Denied

Cantor, Scott E.
In reply to this post by tolock
On 7/27/18, 9:35 AM, "users on behalf of Tabitha O. Locklear" <[hidden email] on behalf of [hidden email]> wrote:

> The old syntax is using 2 of the deprecated values SAML1StringNameIdentifier and SAML2StringNameID.
> I have placed what I thought might would work in the saml-nameid.xml file but I’m still receiving the access is denied
> error message.

Leave it. Just get the V3 system running with the configuration that worked and then worry about cleaning things up, and do *not* build the new one from scratch, upgrade the configuration as documented.

-- 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: Access Denied

tolock
Scott, we have the old version running on and old release of RH we need to move it to RH7.
Therefore, we are building from scratch.
So far during testing all of our SP's work except for the two I have that used the old NameID syntax.

-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Friday, July 27, 2018 1:54 PM
To: Shib Users <[hidden email]>
Subject: Re: Access Denied

On 7/27/18, 9:35 AM, "users on behalf of Tabitha O. Locklear" <[hidden email] on behalf of [hidden email]> wrote:

> The old syntax is using 2 of the deprecated values SAML1StringNameIdentifier and SAML2StringNameID.
> I have placed what I thought might would work in the saml-nameid.xml
> file but I’m still receiving the access is denied error message.

Leave it. Just get the V3 system running with the configuration that worked and then worry about cleaning things up, and do *not* build the new one from scratch, upgrade the configuration as documented.

-- 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]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Tabitha O. Locklear
MS Information Technology
Operations & Systems Analyst
Division of Information Technology
University of North Carolina at Pembroke
tabithao.locklear@uncp.edu
Reply | Threaded
Open this post in threaded view
|

RE: Access Denied

Cantor, Scott E.
> Therefore, we are building from scratch.

No.

You move the system over by hand, and then upgrade over top of it. All that has to be there are the files.
 
-- 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: Access Denied

Cantor, Scott E.
On 7/31/18, 9:15 AM, "Cantor, Scott" <[hidden email]> wrote:

> You move the system over by hand, and then upgrade over top of it. All that has to be there are the files.

To clarify since I was a bit overly brief this morning due to busy-ness, what I'm saying is: if you want to get back to a working system, you can upgrade, and the NameID behavior is going to be identical because all of the components that go into it are left in place by design (whatever you already did for authentication can just be copied over into the upgraded system, that's all different in V3 of course).

The documented upgrade procedure has nothing to do with moving servers or not moving servers, it's simply how it is meant to be done no matter what. It is how *I* did mine, and trust me, I know more about running both V2 and V3 than anybody. When I deviated from the upgrade mid-stream to "clean stuff up", I broke it. It's just unavoidable doing it that way, too many different cases to test or fully reproduce from scratch.

All that said, if you're stuck with a fresh install, then you have no choice but to understand *how* NameID generation works, full stop, and you need to debug the active behavior, which is heavily logged. It is very well documented and if I understood why people seemed to have such trouble with it, I would fix it, but I simply don't.

1. A Format is selected in a precisely documented and rigid sequence of steps that are documented.
2. The generators in the configuration are tried in sequence to satisfy that Format.
3. Failing that, give up and stick in a default (transient).

That's it. The only variable part is that step 2 will also fall back into legacy use of the attribute resolver via the old NameID-based AttributeEncoders attached to AttributeDefinitions to generate the NameIDs, which is what an upgraded system does at first until it's changed. I didn't change mine away from that until months after I had a production V3 system. It is not urgent to do that, short of moving to V4, which is certainly not coming any time soon.

-- 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: Access Denied

tolock
Thank you for your time and your response.
I had so much time into building the V3 and I had all but two SP's working, I felt that it would be a simple fix ; but not understanding the syntax has made if far too difficult.


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Tuesday, July 31, 2018 9:19 PM
To: Shib Users <[hidden email]>
Subject: Re: Access Denied

On 7/31/18, 9:15 AM, "Cantor, Scott" <[hidden email]> wrote:

> You move the system over by hand, and then upgrade over top of it. All that has to be there are the files.

To clarify since I was a bit overly brief this morning due to busy-ness, what I'm saying is: if you want to get back to a working system, you can upgrade, and the NameID behavior is going to be identical because all of the components that go into it are left in place by design (whatever you already did for authentication can just be copied over into the upgraded system, that's all different in V3 of course).

The documented upgrade procedure has nothing to do with moving servers or not moving servers, it's simply how it is meant to be done no matter what. It is how *I* did mine, and trust me, I know more about running both V2 and V3 than anybody. When I deviated from the upgrade mid-stream to "clean stuff up", I broke it. It's just unavoidable doing it that way, too many different cases to test or fully reproduce from scratch.

All that said, if you're stuck with a fresh install, then you have no choice but to understand *how* NameID generation works, full stop, and you need to debug the active behavior, which is heavily logged. It is very well documented and if I understood why people seemed to have such trouble with it, I would fix it, but I simply don't.

1. A Format is selected in a precisely documented and rigid sequence of steps that are documented.
2. The generators in the configuration are tried in sequence to satisfy that Format.
3. Failing that, give up and stick in a default (transient).

That's it. The only variable part is that step 2 will also fall back into legacy use of the attribute resolver via the old NameID-based AttributeEncoders attached to AttributeDefinitions to generate the NameIDs, which is what an upgraded system does at first until it's changed. I didn't change mine away from that until months after I had a production V3 system. It is not urgent to do that, short of moving to V4, which is certainly not coming any time soon.

-- 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]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Tabitha O. Locklear
MS Information Technology
Operations & Systems Analyst
Division of Information Technology
University of North Carolina at Pembroke
tabithao.locklear@uncp.edu
Reply | Threaded
Open this post in threaded view
|

Re: Access Denied

Peter Schober
* Tabitha O. Locklear <[hidden email]> [2018-08-01 17:18]:
> I had so much time into building the V3 and I had all but two SP's
> working, I felt that it would be a simple fix ; but not
> understanding the syntax has made if far too difficult.

I have tried to provide an answer to your original problem report.
If you don't understand something or need more detailed explanations
you could ask (even if the reply might be a pointer to existing
documentation).
-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: Access Denied

Cantor, Scott E.
In reply to this post by tolock
> I had so much time into building the V3 and I had all but two SP's working, I
> felt that it would be a simple fix ; but not understanding the syntax has made
> if far too difficult.

As Peter just said, not knowing what you don't understand or what "this syntax" specifically means makes it impossible for me to give you any specific suggestions and the advice I did give is that an upgrade allows the original files that worked before to keep working NameID-wise in all but a very tiny set of cases.

-- 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: Access Denied

tolock
In reply to this post by Peter Schober

I copied the V2 config attribute-resolver.xml and attribute-filter.xml files onto the V3 server

The saml-nameid.properties are configured for legacy.

# Comment out to disable legacy NameID generation via Attribute Resolver

idp.nameid.saml2.legacyGenerator = shibboleth.LegacySAML2NameIDGenerator

idp.nameid.saml1.legacyGenerator = shibboleth.LegacySAML1NameIdentifierGenerator

 

 

The result is the same as before Access Is Denied.

The report from the SP

 

 

 

 

 

Back when we first created a login for our SP we used this documentation.  

1.  have a deny policy to not release transient ID

2.  new definition for username in resolver the username not as string, but nameid

3.  release this username to SP

4. nameid's cannot be encrypted

 

 

In our Attribute-Filter.xml we have

STEP 1:

    <afp:AttributeFilterPolicy id="releaseTransientId">

        <afp:PolicyRequirementRule xsi:type="basic:NOT">

        <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://xxxx-stg.saasit.com/" />

        </afp:PolicyRequirementRule>

        <afp:AttributeRule attributeID="transientId">

            <afp:PermitValueRule xsi:type="basic:ANY"/>

        </afp:AttributeRule>

    </afp:AttributeFilterPolicy>

 

STEP 2:

<resolver:AttributeDefinition id="Login" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"

        sourceAttributeID="sAMAccountName">

        <resolver:Dependency ref="myAD" />

        <resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"

            nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:transient" />

        <resolver:AttributeEncoder xsi:type="SAML2StringNameID" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"

                                nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />

    </resolver:AttributeDefinition>

 

STEP 3:

<AttributeFilterPolicy id="releaseLoginToSAASIT">

        <PolicyRequirementRule xsi:type="Requester" value="https://uncp-stg.saasit.com/" />

 

        <AttributeRule attributeID="Login">

        <PermitValueRule xsi:type="ANY" />

        </AttributeRule>

        </AttributeFilterPolicy>

 

 

I copied the relying-party.xml.dist file and inserted the part for the SP.

Relying-Party.xml

 

 

STEP 4.

 

<!-- Container for any overrides you want to add. -->

 

    <util:list id="shibboleth.RelyingPartyOverrides">

   

        <!--                                                                                   

                     Override example that identifies a single RP by name and configures it

        for SAML 2 SSO without encryption. This is a common "vendor" scenario.

        -->

              

                <bean parent="RelyingPartyByName" c:relyingPartyIds="https://xxxx-stg.saasit.com/">

        <property name="profileConfigurations">

            <list>

            <bean parent="SAML2.SSO" p:encryptNameIDs="false" p:encryptAssertions="false" />

            <bean parent="SAML2.AttributeQuery" p:encryptAssertions="false" p:encryptNameIDs="false" />

            </list>

        </property>

    </bean>

 

    </util:list>

 

 

 

But the result is still the same.

 

 

 

 

-----Original Message-----
From: users <[hidden email]> On Behalf Of Peter Schober
Sent: Wednesday, August 01, 2018 11:23 AM
To: [hidden email]
Subject: Re: Access Denied

 

* Tabitha O. Locklear <[hidden email]> [2018-08-01 17:18]:

> I had so much time into building the V3 and I had all but two SP's

> working, I felt that it would be a simple fix ; but not understanding

> the syntax has made if far too difficult.

 

I have tried to provide an answer to your original problem report.

If you don't understand something or need more detailed explanations you could ask (even if the reply might be a pointer to existing documentation).

-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]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Tabitha O. Locklear
MS Information Technology
Operations & Systems Analyst
Division of Information Technology
University of North Carolina at Pembroke
tabithao.locklear@uncp.edu
Reply | Threaded
Open this post in threaded view
|

RE: Access Denied

Cantor, Scott E.
> Back when we first created a login for our SP we used this documentation.
>
> 1.  have a deny policy to not release transient ID

That was never the way to do it, never anything we documented (or nothing I did anyway) and it will not work in V3.

You have to cause a Format selection to be made, you can't rely on the system to accidentally do the right thing by blocking the wrong thing. Transient's always going to be a fallback and if you're not getting a Format selected expliitly, then it's going to keep defaulting to that.

-- 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: Access Denied

Robert Bradley
In reply to this post by tolock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/08/18 19:49, Tabitha O. Locklear wrote:

> Back when we first created a login for our SP we used this
> documentation.
>
> 1.  have a deny policy to not release transient ID
>
> 2.  new definition for username in resolver the username not as
> string, but nameid
>
> 3.  release this username to SP
>
> 4. nameid's cannot be encrypted
>
>
>
>
>
> In our Attribute-Filter.xml we have
>
> STEP 1:
>
> <afp:AttributeFilterPolicy id="releaseTransientId">
>
> <afp:PolicyRequirementRule xsi:type="basic:NOT">
>
> <basic:Rule xsi:type="basic:AttributeRequesterString"
> value="https://xxxx-stg.saasit.com/" />
>
> </afp:PolicyRequirementRule>
>
> <afp:AttributeRule attributeID="transientId">
>
> <afp:PermitValueRule xsi:type="basic:ANY"/>
>
> </afp:AttributeRule>
>
> </afp:AttributeFilterPolicy>
>
>
>
> STEP 2:
>
> <resolver:AttributeDefinition id="Login" xsi:type="Simple"
> xmlns="urn:mace:shibboleth:2.0:resolver:ad"
>
> sourceAttributeID="sAMAccountName">
>
> <resolver:Dependency ref="myAD" />
>
> <resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier"
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>
> nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:transient"
> />
>
> <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>
> nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> />
>
> </resolver:AttributeDefinition>
>
>
>
> STEP 3:
>
> <AttributeFilterPolicy id="releaseLoginToSAASIT">
>
> <PolicyRequirementRule xsi:type="Requester"
> value="https://uncp-stg.saasit.com/" />
>
>
>
> <AttributeRule attributeID="Login">
>
> <PermitValueRule xsi:type="ANY" />
>
> </AttributeRule>
>
> </AttributeFilterPolicy>
>
If that saasit.com entityID is what I think it is, you probably don't
need any of the custom NameID stuff for this...

Instead, you should be able to release the Login attribute as a normal
attribute (called sAMAccountName in this example) and configure HEAT
to use that attribute as the login ID
(https://help.ivanti.com/ht/help/en_US/ISM/2017/Content/Configure/Securi
ty/ADFS%20SAML.htm
has details on the cloud-side of this).  The attribute-resolver.xml
then would look something like (in v3 syntax):

    <resolver:AttributeDefinition id="sAMAccountName"
xsi:type="ad:Simple" sourceAttributeID=id="sAMAccountName">
        <resolver:Dependency ref="myAD" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String"
name="urn:oid:1.2.840.113556.1.4.221" friendlyName="sAMAccountName"
encodeType="false" />
    </resolver:AttributeDefinition>

In the "provisioning attributes" configuration, LoginID would be
mapped to "urn:oid:1.2.840.113556.1.4.221" (MS's OID for sAMAccountName)
.

The attribute-filter.xml fragment would look like:

    <afp:AttributeFilterPolicy id="attributeFilterPolicyForUucpStgSaasit
">
        <afp:PolicyRequirementRule
xsi:type="basic:AttributeRequesterString"
value="https://uncp-stg.saasit.com/" />

        <afp:AttributeRule attributeID="sAMAccountName">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

Lastly, the default signing algorithm used by HEAT is SHA-1.  You will
either need to configure it to use SHA-256 in their Web interface or
use relying-party.xml to override it:

    <bean id="SHA1SecurityConfig"
parent="shibboleth.DefaultSecurityConfiguration"

p:signatureSigningConfiguration-ref="shibboleth.SigningConfiguration.SHA
1"
/>
...
    <util:list id="shibboleth.RelyingPartyOverrides">
        <bean parent="RelyingPartyByName"
c:relyingPartyIds="#{{'https://uncp-stg.saasit.com/',
'https://uncp.saasit.com/'}}">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO"
p:securityConfiguration-ref="SHA1SecurityConfig"
p:signAssertions="true" />
                </list>
            </property>
        </bean>
...
    </util:list>

Hope this helps...

- --
Dr Robert Bradley
Identity and Access Management Team, IT Services, University of Oxford
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEgF3NFfO9FqlA+ME+lGGnynav474FAltq3jgACgkQlGGnynav
476PSA/9GvBc2klBXapMl+V+G4BRhMGuZq2wYF7FBrIX/5SYEDy+CCAd/Xmn7dM4
EvAD0XjJjhdXiYrlVACoF+GPQfNYP3O2VpCLGBJWbVh6nBQLRQS2pQMH1xjss2QA
JhJJM5STM83ndmMorFGNVaDIiFKKOw80TS7frTh1RQcZxije2XQ1njqaxC6wBvP/
yY/P4tHXbA/bwRJnWEEn5PsU13DEE0Bi89djOKPBNuGqmgV4A0AbHEs9WWA6zrtz
B50jtMnjt/EWofV2iu6RKDvuW93iH5bOSGWVym9DB00T1UqzHsr3KjbJxhbwACBU
Ym1Ma+musaTX/jOdBWdHwVZTpt7m6qiuqATvToJqumNlVcr+MIdJPwG4d3IXR/Qq
eXOBBxqpDWASdvGZw0X8ALs3s2zaPGAjuBoNnWRCFrUQigJ0v1JyPKhDZjt+GUlC
42uuKbEqvsedjb5/h+qlHSHwSDp8AmdhIcnrkGEkZN5brxhsTUAjSecONngysWZ4
jl6Q8jH7CY3kvefDAjiIWoDBbr/SdR/RZOr9bc7ASlyZGBgmrAxnFYYwHcK0QAZK
KLgGgC6IHJsM2UAB3G/jCcL+oDHJdP9B8QD1XrbflK0tsmxh3Ik1MLrM0WK0Nyef
oX6XBOQ2spbQsxRBdszsgrH8S1EsvgXKYEjdVVrRSqSFLPzjWpE=
=PSKD
-----END PGP SIGNATURE-----
--
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: Access Denied

tolock
Robert, I have tried your suggestions and I'm still getting the same response.
Access is denied.
Here is what I find in the logs.

2018-08-08 17:29:18,060 - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAttributeStatementToAssertion:118] - Profile Action AddAttributeStatementToAssertion: Adding constructed AttributeStatement to Assertion _0919c27085387f5491745334edfb3b07
2018-08-08 17:29:18,100 - DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:100] - Configuration specifies the following formats: []
2018-08-08 17:29:18,101 - DEBUG [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:113] - Configuration did not specify any formats, relying on metadata alone
2018-08-08 17:29:18,201 - DEBUG [net.shibboleth.idp.saml.saml2.profile.delegation.impl.DecorateDelegatedAssertion:585] - Found Assertion with AuthnStatement to decorate in outbound Response
2018-08-08 17:29:18,201 - DEBUG [net.shibboleth.idp.saml.saml2.profile.delegation.impl.DecorateDelegatedAssertion:288] - Issuance of delegated was not indicated, skipping assertion decoration


-----Original Message-----
From: users <[hidden email]> On Behalf Of Robert Bradley
Sent: Wednesday, August 08, 2018 8:13 AM
To: [hidden email]
Subject: Re: Access Denied

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/08/18 19:49, Tabitha O. Locklear wrote:

> Back when we first created a login for our SP we used this
> documentation.
>
> 1.  have a deny policy to not release transient ID
>
> 2.  new definition for username in resolver the username not as
> string, but nameid
>
> 3.  release this username to SP
>
> 4. nameid's cannot be encrypted
>
>
>
>
>
> In our Attribute-Filter.xml we have
>
> STEP 1:
>
> <afp:AttributeFilterPolicy id="releaseTransientId">
>
> <afp:PolicyRequirementRule xsi:type="basic:NOT">
>
> <basic:Rule xsi:type="basic:AttributeRequesterString"
> value="https://xxxx-stg.saasit.com/" />
>
> </afp:PolicyRequirementRule>
>
> <afp:AttributeRule attributeID="transientId">
>
> <afp:PermitValueRule xsi:type="basic:ANY"/>
>
> </afp:AttributeRule>
>
> </afp:AttributeFilterPolicy>
>
>
>
> STEP 2:
>
> <resolver:AttributeDefinition id="Login" xsi:type="Simple"
> xmlns="urn:mace:shibboleth:2.0:resolver:ad"
>
> sourceAttributeID="sAMAccountName">
>
> <resolver:Dependency ref="myAD" />
>
> <resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier"
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>
> nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:transient"
> />
>
> <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
> xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>
> nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
> />
>
> </resolver:AttributeDefinition>
>
>
>
> STEP 3:
>
> <AttributeFilterPolicy id="releaseLoginToSAASIT">
>
> <PolicyRequirementRule xsi:type="Requester"
> value="https://uncp-stg.saasit.com/" />
>
>
>
> <AttributeRule attributeID="Login">
>
> <PermitValueRule xsi:type="ANY" />
>
> </AttributeRule>
>
> </AttributeFilterPolicy>
>
If that saasit.com entityID is what I think it is, you probably don't need any of the custom NameID stuff for this...

Instead, you should be able to release the Login attribute as a normal attribute (called sAMAccountName in this example) and configure HEAT to use that attribute as the login ID (https://help.ivanti.com/ht/help/en_US/ISM/2017/Content/Configure/Securi
ty/ADFS%20SAML.htm
has details on the cloud-side of this).  The attribute-resolver.xml then would look something like (in v3 syntax):

    <resolver:AttributeDefinition id="sAMAccountName"
xsi:type="ad:Simple" sourceAttributeID=id="sAMAccountName">
        <resolver:Dependency ref="myAD" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String"
name="urn:oid:1.2.840.113556.1.4.221" friendlyName="sAMAccountName"
encodeType="false" />
    </resolver:AttributeDefinition>

In the "provisioning attributes" configuration, LoginID would be mapped to "urn:oid:1.2.840.113556.1.4.221" (MS's OID for sAMAccountName) .

The attribute-filter.xml fragment would look like:

    <afp:AttributeFilterPolicy id="attributeFilterPolicyForUucpStgSaasit
">
        <afp:PolicyRequirementRule
xsi:type="basic:AttributeRequesterString"
value="https://uncp-stg.saasit.com/" />

        <afp:AttributeRule attributeID="sAMAccountName">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

Lastly, the default signing algorithm used by HEAT is SHA-1.  You will either need to configure it to use SHA-256 in their Web interface or use relying-party.xml to override it:

    <bean id="SHA1SecurityConfig"
parent="shibboleth.DefaultSecurityConfiguration"

p:signatureSigningConfiguration-ref="shibboleth.SigningConfiguration.SHA
1"
/>
...
    <util:list id="shibboleth.RelyingPartyOverrides">
        <bean parent="RelyingPartyByName"
c:relyingPartyIds="#{{'https://uncp-stg.saasit.com/',
'https://uncp.saasit.com/'}}">
            <property name="profileConfigurations">
                <list>
                    <bean parent="SAML2.SSO"
p:securityConfiguration-ref="SHA1SecurityConfig"
p:signAssertions="true" />
                </list>
            </property>
        </bean>
...
    </util:list>

Hope this helps...

- --
Dr Robert Bradley
Identity and Access Management Team, IT Services, University of Oxford -----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEgF3NFfO9FqlA+ME+lGGnynav474FAltq3jgACgkQlGGnynav
476PSA/9GvBc2klBXapMl+V+G4BRhMGuZq2wYF7FBrIX/5SYEDy+CCAd/Xmn7dM4
EvAD0XjJjhdXiYrlVACoF+GPQfNYP3O2VpCLGBJWbVh6nBQLRQS2pQMH1xjss2QA
JhJJM5STM83ndmMorFGNVaDIiFKKOw80TS7frTh1RQcZxije2XQ1njqaxC6wBvP/
yY/P4tHXbA/bwRJnWEEn5PsU13DEE0Bi89djOKPBNuGqmgV4A0AbHEs9WWA6zrtz
B50jtMnjt/EWofV2iu6RKDvuW93iH5bOSGWVym9DB00T1UqzHsr3KjbJxhbwACBU
Ym1Ma+musaTX/jOdBWdHwVZTpt7m6qiuqATvToJqumNlVcr+MIdJPwG4d3IXR/Qq
eXOBBxqpDWASdvGZw0X8ALs3s2zaPGAjuBoNnWRCFrUQigJ0v1JyPKhDZjt+GUlC
42uuKbEqvsedjb5/h+qlHSHwSDp8AmdhIcnrkGEkZN5brxhsTUAjSecONngysWZ4
jl6Q8jH7CY3kvefDAjiIWoDBbr/SdR/RZOr9bc7ASlyZGBgmrAxnFYYwHcK0QAZK
KLgGgC6IHJsM2UAB3G/jCcL+oDHJdP9B8QD1XrbflK0tsmxh3Ik1MLrM0WK0Nyef
oX6XBOQ2spbQsxRBdszsgrH8S1EsvgXKYEjdVVrRSqSFLPzjWpE=
=PSKD
-----END PGP SIGNATURE-----
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Tabitha O. Locklear
MS Information Technology
Operations & Systems Analyst
Division of Information Technology
University of North Carolina at Pembroke
tabithao.locklear@uncp.edu
Reply | Threaded
Open this post in threaded view
|

RE: Access Denied

Cantor, Scott E.
> 2018-08-08 17:29:18,100 - DEBUG
> [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:10
> 0] - Configuration specifies the following formats: []

So you are not choosing a Format in relying-party.xml, which is fine, that's not the recommended way to do it unless you have to because you're trying to forcibly use the "unspecified" Format constant.

> 2018-08-08 17:29:18,101 - DEBUG
> [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStrategy:11
> 3] - Configuration did not specify any formats, relying on metadata alone

And you have the metadata, so you know whether it is specifying any Format(s). And if not, and you have to rely on a NameID, then you would have to change that.

If the answer to both methods of Format selection is that they're not being used, then it's going to choose the default Format, which is transient. Which I would imagine is what it's doing?

-- 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: Access Denied

tolock
Scott when I look at the logs for our old V2 (production instance) it looks as though it's looking for a transient Id to encode.

14:17:28.594 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:548] - Filtering out potential name identifier attributes which do not support one of the following formats: [urn:oasis:names:tc:SAML:2.0:nameid-format:transient]
14:17:28.594 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:567] - Retaining attribute Login which may be encoded as a name identifier of format urn:oasis:names:tc:SAML:2.0:nameid-format:transient
14:17:28.594 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:567] - Retaining attribute transientId which may be encoded as a name identifier of format urn:oasis:names:tc:SAML:2.0:nameid-format:transient
14:17:28.594 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:672] - Selecting attribute to be encoded as a name identifier by encoder of type edu.internet2.middleware.shibboleth.common.attribute.encoding.SAML2NameIDEncoder
14:17:28.594 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:699] - Selecting the first attribute that can be encoded in to a name identifier
14:17:28.595 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:483] - Name identifier for relying party 'https://uncp-stg.saasit.com/' will be built from attribute 'Login'
14:17:28.595 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:864] - Using attribute 'Login' supporting NameID format 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient' to create the NameID for relying party 'https://uncp-stg.saasit.com/'

-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, August 08, 2018 1:58 PM
To: Shib Users <[hidden email]>
Subject: RE: Access Denied

> 2018-08-08 17:29:18,100 - DEBUG
> [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStra
> tegy:10 0] - Configuration specifies the following formats: []

So you are not choosing a Format in relying-party.xml, which is fine, that's not the recommended way to do it unless you have to because you're trying to forcibly use the "unspecified" Format constant.

> 2018-08-08 17:29:18,101 - DEBUG
> [net.shibboleth.idp.saml.profile.logic.DefaultNameIdentifierFormatStra
> tegy:11 3] - Configuration did not specify any formats, relying on
> metadata alone

And you have the metadata, so you know whether it is specifying any Format(s). And if not, and you have to rely on a NameID, then you would have to change that.

If the answer to both methods of Format selection is that they're not being used, then it's going to choose the default Format, which is transient. Which I would imagine is what it's doing?

-- 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]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Tabitha O. Locklear
MS Information Technology
Operations & Systems Analyst
Division of Information Technology
University of North Carolina at Pembroke
tabithao.locklear@uncp.edu
Reply | Threaded
Open this post in threaded view
|

RE: Access Denied

Cantor, Scott E.
> Scott when I look at the logs for our old V2 (production instance) it looks as
> though it's looking for a transient Id to encode.

Transient IDs are completely different in V3, they are never attributes and nothing related to them in the resolver is used in any way. The log should say that explicitly in a warning, and if not you should report that.

What you are doing with a deny rule is not the proper way to configure the IdP. That's why I said that, explicitly, already. That's why the upgrade failed and it will continue to fail.

If you don't want a default choice, the Format must be selected explicitly. Always. There is no other way to get it to work. I don't really know how else to say it. There is no supported means of controlling the Format used except what's documented and it was the same in V2 and V3. You were using an unsupported way of getting an accidental result that happened to fit what you wanted it to do.

-- 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]