Oracle Web Services Security 10-5
10.2.3.1 Creating a Username Token
First, create a UsernameToken and place it inside your WSSecurity header. The only mandatory field in the UsernameToken is the username:
create a Username token WSSecurity ws = ...
UsernameToken ut = new UsernameTokendoc; ut.setUserNameZoe;
remember to put this inside your WSSecurity header. addUserNameToken puts it at the beginning, you can also
use a regular DOM method appendChild or insertChild to put it in. ws.addUsernameTokenut;
optionally add an wsu:Id, so you can refer to it ut.setWsuIdMyUser;
Next, decide how to put the password into this token. There are several choices:
1.
Add a clear text password. Consider using this technique only when the whole message is being sent over a secure channel like SSL.
2.
Add a digest of the password or some other kind of derived password. A digest is not necessarily more secure than a clear text password, as it can also be replayed
unless it is protected by a nonce and time.
3.
Add a digest of the password using the digest mechanism given in the WS Security specification. This uses the nonce and the createdDate.
4.
Do not add the password or its digest at all. Instead derive a key from the password and use that to sign the message, to demonstrate knowledge of the key.
For options 1 and 2, use the setPassword method ut.setPasswordIloveDogs;
With this mechanism, the reciever should simply call UsernameToken.getPassword to check if the password is as expected.
For option 3, use the setPasswordDigest method, but before doing thatfor that you have to at first set a nonce and a created date.
SecureRandom random = SecureRandom.getInstanceSHA1PRNG; byte nonce[] = new byte[20];
random.nextBytesnonce; compute a 20 byte random nonce ut.setNoncenonce;
ut.setCreatedDatenew Date; Set the date to now ut.setPasswordDigestIloveDogs; will compute the digest from
this clear text password using
SAML Assertion 1.1 oracle.security.xmlsec.wss.sa
ml.SAMLAssertionToken
SAML Assertion 2.0 oracle.security.xmlsec.wss.sa
ml2. SAML2AssertionToken
■
holder_of_key
■
sender_vouchers
■
bearer For holder_of_key the
subject’s key is used – this is, the key inside the
saml:SubjectConfirmation which is inside the
saml:Assertion.
For sender_vouches, the key of the attesting entity is used.
Keys are not extracted from bearer tokens.
Table 10–2 Cont. Security Tokens for Oracle Web Services Security
Type of Token Java Class Variations
Keys
10-6 Oracle Fusion Middleware Reference for Oracle Security Developer Tools
nonce and createdDate For this mechanism, the reciever should use the following
byte nonce[] = ut.getNonce; .. check against the used nonces, to make sure this is a new nonce
Date createdDate = ut.getCreated; .. check that this createdDate is within an expected clock skew
boolean valid = ut.isValiduserName, passwd, above call will recompute the digest from the passwd
and the nonce and created date, and check if this digest matches the digest in the username token
For option 4, set the salt and iteration count SecureRandom random = SecureRandom.getInstanceSHA1PRNG;
byte salt[] = new byte[15]; random.nextBytessalt; compute a 15 byte random salt
ut.setSalt1, salt; ut.setIteration1000;
SecretKey key = ut.deriveKeyIloveDogs;
Now you can use this secret key to sign or encrypt data.
10.2.3.2 Creating an X509 Token
Kategori