[mitreid-connect] Support for Resource Owner Password Credentials

[Luiz Omori]

Any idea of which event could be used to attach the time stamper to? Also, any concerns about the http sessions?

Regards,
Luiz

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Thursday, June 18, 2015 at 11:30 AM
To: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Support for Resource Owner Password Credentials

Setting the auth time from the issue time would be very bad, as it gives a dangerously incorrect view of what the authentication context was.

The real fix is to have the oauth:password component tied into the time stamper so that the authentication event can be correctly recorded. Right now, your setup is bypassing this, which is causing the cascading errors.

 — Justin

On Jun 18, 2015, at 10:35 AM, Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

Actually, perhaps this, minus logs, would be even better:

                    Long authTimestamp = (issueTime!=null) ? issueTime.getTime() : null;

                    if (request.getExtensions().get(AuthenticationTimeStamper.AUTH_TIMESTAMP)!=null) {
                        authTimestamp = Long.parseLong((String)
                                request.getExtensions().get(AuthenticationTimeStamper.AUTH_TIMESTAMP));
                    }

                    if (authTimestamp != null) {
                        idClaims.setClaim("auth_time", authTimestamp / 1000L);
                        logger.debug("auth_time:" + idClaims.getClaim("auth_time"));
                    } else {
                        logger.debug("auth_time: not available");
                    }

…which is using the issueTime as a fallback to set the auth_time claim.  This sounds reasonable to me however don’t have the full picture so may actually be bad, don’t know.

Now the real design aspect here is that this time appears to be set by AuthenticationTimeStamper which in turn is called by the authorization success event from the login page, which is absent in this flow. I was wondering if another event could be used for calling this setter, but also came across the fact that http session was being used to store it. I don’t know the implications of using that storage/passing parameters mechanism in this possibly browser-less flow. Maybe you are using some kind of virtual sessions? Other parameters may be affected as well. In any case, I tested the returned tokens using two custom applications to exchange tokens between them, making sure that there was no problems related to sessions and it seems to work fine.

Regards,
Luiz


From: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Date: Wednesday, June 17, 2015 at 3:19 PM
To: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Support for Resource Owner Password Credentials

The minor change below in DefaultOIDCTokenService.java::createIdToken to check if AuthenticationTimeStamper.AUTH_TIMESTAMP is defined handles the problem from the pure code point of view. Not sure yet if that property is mandatory or not. Will check where it could be defined.

                        if (request.getExtensions().get(AuthenticationTimeStamper.AUTH_TIMESTAMP)!=null) {
                            Long authTimestamp =
                                    Long.parseLong((String) request.getExtensions().get(AuthenticationTimeStamper.AUTH_TIMESTAMP));

                            if (authTimestamp != null) {
                                    idClaims.setClaim("auth_time", authTimestamp / 1000L);
                            }
                        }

Regards,
Luiz

From: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Date: Wednesday, June 17, 2015 at 2:15 PM
To: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Support for Resource Owner Password Credentials

Thanks. I was looking exactly at that but explicitly set the authentication-manager to “authenticationManager” which apparently causes the invocation of Mitre’s DefaultOAuth2ProviderTokenService down the line. That’s the same one used for the MitreId server itself, right?

<oauth:password authentication-manager-ref="authenticationManager" />

In any case, both seem to have the same behaviour on my system, which is an exception. See partial stack trace below. Will take a look what is causing that but let me know if you know the cause already.

…
</pre><p><b>root cause</b></p><pre>java.lang.NumberFormatException: null
java.lang.Long.parseLong(Long.java:552)
java.lang.Long.parseLong(Long.java:631)
org.mitre.openid.connect.service.impl.DefaultOIDCTokenService.createIdToken(DefaultOIDCTokenService.java:112)
org.mitre.openid.connect.token.ConnectTokenEnhancer.enhance(ConnectTokenEnhancer.java:128)
org.mitre.oauth2.service.impl.DefaultOAuth2ProviderTokenService.createAccessToken(DefaultOAuth2ProviderTokenService.java:178)
org.mitre.oauth2.service.impl.DefaultOAuth2ProviderTokenService.createAccessToken(DefaultOAuth2ProviderTokenService.java:64)
org.springframework.security.oauth2.provider.token.AbstractTokenGranter.getAccessToken(AbstractTokenGranter.java:70)
…

Well, yes, this may be used by legacy system in our case. By the way, what is the official view for this OAuth2 flow under OpenId Connect? I’ve seen arguments about Authorization and Implicit flows being recommended by OpenId Connect, but not explicitly saying that Client Credentials and Resource Owner are not allowed.

Regards,
Luiz


From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Wednesday, June 17, 2015 at 1:34 PM
To: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Support for Resource Owner Password Credentials

Override or edit authz-context.xml and add the following line:

<oauth:password/>

next to all the other grants. And be very careful using this flow, you should only ever use it with highly trusted and legacy clients that can’t open a browser.

 — Justin

On Jun 16, 2015, at 1:29 PM, Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

Hi,

I’ve seen a ticket requesting support for the Resource Owner (grant_type=password) flow and it’s said that it’s already supported but a special server configuration is necessary, possibly accomplished using Maven Overlays. Could you clarify exactly which server reconfiguration is required? Currently I’m building my own test server so don’t really care about Maven Overlays at this point, can hack something directly in the build if necessary.

As you suspect, my client app is getting the error below, even tough the application support for grant type password is checked:

{"error":"unsupported_grant_type","error_description":"Unsupported grant type: password”}

Regards,
Luiz

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/pull/567

_______________________________________________
mitreid-connect mailing list
mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>
http://mailman.mit.edu/mailman/listinfo/mitreid-connect


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150618/ee6b4a6c/attachment-0001.htm