GreenButtonAlliance
multiple retailCustomers are assigned the same access_token
Start with a clean system. Sign in to the third party and authorize allan access to the first data custodian using the first scopestring.
sign out of the third party. sign in to the third party as charles and authorize charles access to the first data custodian using the first scopestring.
Only one authorization/subscription is created and there is no suthorization that referes to charles' retailCustomerId.
Charles is not being assigned an authorization.access_token.
The SOAPUI script EstablishTwoSubscriptions in the Library section implements this scenario. In my tests two authorizations were created and separate authorizations and access tokens were created. Both cases used identical scope strings.
Hi marty, different customers and same Third Party scenario is good. It's working for me as well.
In our scenario, where a customer has multiple services and customer wants to authorize services to a third-party individually.
- If customer has multiple UsagePoints, a single authorization to a single third party authorizes access to all together and/or individually
- If customer has different "scopes" then you can make multiple authorizations for same customer and third party
What need do these two choices not fill?
Please note that this bug is different from the issue Dibyendu entered. This bug is reproducible manually following the steps described in the original comment. To be clear - this is not the same issue https://github.com/energyos/OpenESPI-DataCustodian-java/issues/171
I believe the fault in the scenario was that "alan" had remained logged into the DC when Charles tried to authorize.
I repeated the manual scenario ensuring that alan was logged out of DC after the first authorization. I got two different subscriptions and access tokens:
data_custodian 1 http://localhost:8080/DataCustodian/espi/1_1/resource/Batch/Subscription/5 cb4a21e9-0f08-4f8e-9954-3e84f99a6098 6a94e982-cec5-49e1-9c4d-e993db68635c FB=4_5_15;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13
data_custodian 1 http://localhost:8080/DataCustodian/espi/1_1/resource/Batch/Subscription/6 e5c388f4-5c52-4466-bb46-96110b9fcb22 a70958ca-a4fe-47a1-b217-e1142cd217a0 FB=4_5_15;IntervalDuration=900;BlockDuration=monthly;HistoryLength=13
It is true that if one goes to the DC and performs a logout, that the appropriate two authorizations/access_tokens are created. So that is a good ways to avoid this bug. But the bug is still there.
The scenario as described above depicts the flow described in the GreenButtonAuthorization.docx. That flow does not contain the extra step of going to the DC and signing out. Nor should, IMO, the DC context of authentication be shared between the two authorization flows. The TP authentication context has changed (from alan to charles) - yet the DC's view does not reflect that authentication context change.
Don,
Might this be related to the create-session="never" attribute(s) within oauth-RS-config.xml?
The description of the Spring Security 3.1 xsd for "create-session" is:
Controls the eagerness with which an HTTP session is created by Spring Security classes. If not set, defaults to "ifRequired". If "stateless" is used, this implies that the application guarantees that it will not create a session. This differs from the use of "never" which mans that Spring Security will not create a session, but will make use of one if the application does.
Since the "create-session" parameter description indicates the parameter controls whether an HTTP session is created and if the value is "never" then Spring Security will use a HTTP session if one exists, changing the "never" values to "stateless" would be an interesting test. However, the create-session parameter value for /oauth/token is "stateless" already, so I am doubtful that this is the source of the problem.
I also checked the Spring Security 3.2 xsd and the description for "create-session" is the same in Spring Security 3.2 as I listed previously for Spring Security 3.1.