Using Shibboleth as Service Provider on IBM iSeries

Nathan Hughes nathan.hughes at badgepass.com
Tue Jan 17 18:02:02 EST 2017 

So the proxy will be the SP?  Or will we have a proxy and SP?  
Is it possible to get the SP code, so we can attempt make changes and put it on the iSeries?

Nathan Hughes

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of users-request at shibboleth.net
Sent: Tuesday, January 17, 2017 3:45 PM
To: users at shibboleth.net
Subject: users Digest, Vol 67, Issue 73

Send users mailing list submissions to
	users at shibboleth.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
	users-request at shibboleth.net

You can reach the person managing the list at
	users-owner at shibboleth.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of users digest..."


Today's Topics:

   1. Re: assertion not always signed (Rich Graves)
   2. RE: Using Shibboleth as Service Provider on IBM iSeries
      (Cantor, Scott)
   3. Re: Re: IDP 3.3 MFA flow -- working example (Sheldon, Nathan I)


----------------------------------------------------------------------

Message: 1
Date: Tue, 17 Jan 2017 15:38:47 -0600
From: Rich Graves <rgraves at carleton.edu>
To: Shib Users <users at shibboleth.net>
Subject: Re: assertion not always signed
Message-ID:
	<CA+Gkci2QUVkMVERPjpBeGg3oawU6oXPnxBKYzrWzX2cRpEqafw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

> You apparently do have your fix at least.

Update to 3.3 you mean?

I think the explanation in IDP-1108 (actually IDP-920) is consistent with what we've seen. So it breaks not based on "time that the IdP session was alive," but "whether we have previously had a short-lived session with this SP during the same long-lived IdP session."

The quick and dirty 3.3 ./install.sh seems to have worked after a) removing the redundant DuoWeb-*.jar and b) restoring the pre-3.3 behavior of leaving credentials in RAM for a while. Is there a quick fix to replace usernamePasswordContext.getUsername()  with a call to get the principal elsewhere? Longer-term fix is to switch to the new
3.3 MFA framework, which doesn't look hard, so it's likely that'll be the short-term fix after all. Here's where the legacy Duo (not
Unicode) chokes "out of the box."

2017-01-17 07:37:40,901 - ERROR
[org.springframework.webflow.execution.ActionExecutionException:76] -
org.springframework.webflow.execution.ActionExecutionException:
Exception thrown executing [AnnotatedAction at 53712e8a targetAction =
[EvaluateAction at 676d5124 expression =
T(com.duosecurity.integrations.DuoShibboleth).instance(environment.getProperty('duo.ikey',
''), environment.getProperty('duo.skey', ''), environment.getProperty('duo.akey', ''), environment.getProperty('duo.host', ''), usernamePasswordContext.getUsername()), resultExpression = flowScope.duo], attributes = map[[empty]]] in state 'null' of flow 'authn/Duo' -- action execution attributes were 'map[[empty]]'
        at org.springframework.webflow.execution.ActionExecutor.execute(ActionExecutor.java:60)
Caused by: org.springframework.binding.expression.EvaluationException:
An ELException occurred getting the value for expression 'T(com.duosecurity.integrations.DuoShibboleth).instance(environment.getProperty('duo.ikey',
''), environment.getProperty('duo.skey', ''), environment.getProperty('duo.akey', ''), environment.getProperty('duo.host', ''), usernamePasswordContext.getUsername())' on context [class org.springframework.webflow.engine.impl.RequestControlContextImpl]
        at org.springframework.binding.expression.spel.SpringELExpression.getValue(SpringELExpression.java:92)
Caused by: org.springframework.expression.spel.SpelEvaluationException:
EL1011E:(pos 46): Method call: Attempted to call method getUsername() on null context object
        at org.springframework.expression.spel.ast.MethodReference.throwIfNotNullSafe(MethodReference.java:144)


------------------------------

Message: 2
Date: Tue, 17 Jan 2017 21:39:03 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
To: Shib Users <users at shibboleth.net>
Subject: RE: Using Shibboleth as Service Provider on IBM iSeries
Message-ID:
	<9846A6064BD102419D06814DD0D78DE11BF861DC at CIO-TNC-D2MBX02.osuad.osu.edu>
	
Content-Type: text/plain; charset="us-ascii"

> 	1.  A user attempts to visit a protected website
> 	2.  The web server on our iSeries proxies over to, say a Windows PC 
> with shibboleth, as the SP

Proxies sit in front. Nobody can access your system directly at all, only the proxy. That is the only possible way to do authentication on the web without deploying software for authentication on the server with the resource. I really have no comment on anything else, I'm only trying to communicate that simple fact. That's what the wiki page is trying to get across.
 
You either put software onto the iSeries box or you proxy. Full stop. Be it SAML, CAS, OIDC, basic-auth, I don't care what it is. The questions are whether to proxy or if not, what software you put on the iSeries. That's really it.

-- Scott



------------------------------

Message: 3
Date: Tue, 17 Jan 2017 21:44:39 +0000
From: "Sheldon, Nathan I" <Nathan.Sheldon at ucsf.edu>
To: "users at shibboleth.net" <users at shibboleth.net>
Subject: Re: Re: IDP 3.3 MFA flow -- working example
Message-ID: <3EF12D99-6291-4C8F-B5EE-BBB381DBCA84 at ucsf.edu>
Content-Type: text/plain; charset="utf-8"

Hi Joe and/or Scott.

I?m trying to get Duo working on a clean Shibboleth IdP 3.3 install (in a development environment for now) and am stumped as to why the IdP isn?t sending me to the duo web flow after successful authentication.  I?m hoping you can provide a missing link that I?m obviously missing somewhere.

Here?s a summary of the files I?ve edited in the /opt/shibboleth-idp/conf directory.

??
attribute-filter.xml (to enable SSO testing) attribute-resolver.xml (? ? ") metadata-providers.xml (? ? ?) relying-party.xml (? ? ?)

logback.xml (Modified to enable DEBUG level logging for most logging).

idp.properties (typical install changes for entityID and scope plus?) modified property to idp.authn.flows = Password|Duo|MFA modified properties to enable SLO.
ensured that idp.additionalProperties includes /conf/authn/duo.properties

ldap.properties (typical install changes for authenticated attribute resolution)

authn/duo.properties
modified properties idp.duo.apiHost, idp.udo.applicationKey, idp.duo.integrationKey, and idp.duo.secretKey to match those provided in the Duo admin web console.

authn/general-authn.xml
replaced c:classRef="http://example.org/ac/classes/mfa" /> with c:classRef="http://id.incommon.org/assurance/mfa" /> replaced c:method="http://example.org/ac/classes/mfa" /> with c:method="http://id.incommon.org/assurance/mfa" />

authn/jaas.config (Modified to work with our multiple AD LDAP proxies)

authn/mfa-authn-config.xml (Made all the modifications Scott described in his previous message in this thread).

authn/password-authn-config.xml
uncommented <import resource="jaas-authn-config.xml" /> commented out <import resource="ldap-authn-config.xml" /> ??

Authentication works, and after successful authentication, I?m presented with the attribute release consent form.  Consenting to the release correctly redirects to the SP and passes the SAML response.  SSO succeeds.  However, I?m never presented with a Duo authentication request.  Logs don?t show any Duo flow activity other than upon initial Shibboleth IdP startup indicating that the flow is registered.

Is something needed in the duo-authn-config.xml file?  I didn?t see any documentation that specifically said that needed to be edited in order to enable it unless you wanted custom conditions (which I don?t, yet anyway).

Regards,
Nathan
----
Nathan Sheldon
IAM Support Engineer
    Identity and Access Management,
    Information Technology Services
University of California, San Francisco





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170117/3f8f5b19/attachment.html>

------------------------------

Subject: Digest Footer

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

------------------------------

End of users Digest, Vol 67, Issue 73
*************************************

More information about the users mailing list