23:26, EEST
March 26, 2014
Hi,
I would like to know if it is possible to accept IssuedToken on the server side (JWT for instance). I would validate the token myself, but at the moment does the server allows to accept them? It is not in UserTokenPolicies class.
On the client side it seems to be possible by using UserIdentity(byte[]).
Thanks,
15:23, EEST
April 3, 2012
Hi,
It is (as far as I know) a pretty-much-not-used feature of OPC UA.
Anyway, for the server side, you can just make an UserTokenPolicy and add that.
issuedTokenPolicy.setTokenType(UserTokenType.IssuedToken);
issuedTokenPolicy.setIssuedTokenType("IssuedTokenTypeHere");
issuedTokenPolicy.setIssuerEndpointUrl("IssuerEndpointUrlHere");
issuedTokenPolicy.setPolicyId("issued_token_invent_something");
issuedTokenPolicy.setSecurityPolicyUri(SecurityPolicy.BASIC256SHA256.getPolicyUri()); //something here as well, but must be a known security policy uri
server.addUserTokenPolicy(issuedTokenPolicy);
For the client side, it would seem we have a bug. The policy id is not set in the token thus we send null (so in practice the server will treat it as an Anonymous usertoken type). This is now fixed in our latest beta and will be part of 4.6.0.
P.S.
Some new stuff in OPC UA 1.04 does refer to JWTs.
https://reference.opcfoundation.org/v104/Core/docs/Part4/7.36.2/#7.36.2.3
https://reference.opcfoundation.org/v104/Core/docs/Part4/7.36.6/
https://reference.opcfoundation.org/v104/Core/docs/Part7/6.6.172/
Though it should be noted that we have not worked on those yet.
23:31, EEST
March 26, 2014
23:54, EEST
March 26, 2014
Hi,
I tested with the 4.6.0 release and I’m able to send a byte array as IssuedToken with your sample code 🙂
My issue is that it seems the content is limited to 245 bytes whereas my JWT token are clearly bigger than that (> 650 bytes). Is there a way to change the RSA algorithm for something that supports bigger content or is it simply not possible to use big tokens? (I already tried to use the token as password for Username/Password but there is exactly the same limitation). I also tried to replace “BASIC256SHA256” by NONE or other policies without success.
Caused by: com.prosysopc.ua.stack.common.ServiceResultException: Bad_SecurityPolicyRejected (code=0x80550000, description="javax.crypto.IllegalBlockSizeException:Data must not be longer than 245 bytes")
at com.prosysopc.ua.stack.utils.EndpointUtil.createIssuedIdentityToken(SourceFile:160)
Thanks 🙂
14:00, EEST
April 3, 2012
The answer is (once again) complicated. The short version is that basically we do not yet support JWT(s) or anything that would require EncryptedSecret; The question is that how much you need this and when?
That password limit is a bug, though to other direction, the limit should actually be 64bytes, due to https://reference.opcfoundation.org/v104/Core/docs/Part4/7.36.2/:
“The legacy token secret format defined in 7.36.2.2 is not extensible and provides only encryption but the encrypted data is not signed. It is used together with the USERNAME_1 UserIdentityToken. The password secret exchanged with this format shall not exceed 64 bytes.”
1.04 defined new “7.36.2.3 EncryptedSecret Format” and also sort of re-wrote the issued token and there is some “native” support for JWT’s, https://reference.opcfoundation.org/Core/docs/Part4/7.36.6/. That would seem to need the EncryptedSecret Format:
“The IssuedIdentityToken is used to pass SecurityTokens issued by an external Authorization Service to the Server. These tokens may be text or binary.
OAuth2 defines a standard for Authorization Services that produce JSON Web Tokens (JWT). These JWTs are passed as an Issued Token to an OPC UA Server which uses the signature contained in the JWT to validate the token. OPC 10000-6 describes OAuth2 and JWTs in more detail. If the token is encrypted, it shall use the EncryptedSecret format defined in 7.36.2.3.”
previously (pre-1.04) it was
“The IssuedIdentityToken is used to pass W S-Security compliant SecurityTokens to the Server. WS-Security defines a number of token profiles that may be used to represent different types of
SecurityTokens. For example, Kerberos and SAML tokens have W SS token profiles and shall be
exchanged in OPC UA as XML Security Tokens.
…
“
The 1.04 part 6 link: https://reference.opcfoundation.org/Core/docs/Part6/6.5.2/, that tells what the issuedTokenType and issuerEndpointUrl should contain if it is a JWT.
The encryption algorithm parameter in the token is The URI of the AsymmetricEncryptionAlgorithm. This goes a bit outside of what I usually do, thus this part might be incorrect. I think the limiting factor is the cert size, and basically there is no way around that: https://stackoverflow.com/questions/10007147/getting-a-illegalblocksizeexception-data-must-not-be-longer-than-256-bytes-when .
The EncryptedSecret would use symmetric encryption algorithm so size would not be a problem. And I think this symmetric key would then be encrypted with the asymmetric algo using the public key as in the “legacy token”.
Technically the limits on the token size as it is now is: 1k cert: 117bytes, 2k cert: 245bytes, 4k cert: 501bytes, anything larger would need the EncryptedSecret support (plus not sure is this only for JWTs yet).
Most Users Ever Online: 1919
Currently Online:
14 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 735
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1523
Posts: 6449
Newest Members:
rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettinger, howardkennerley, Thomassnism, biancacraft16Moderators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1