Possible to decouple client from STS in "STS Issued Token"?

[metro-3]

It seems odd to me that when using STS Issued Token security mechanism that the client is coupled to the STS via WSIT configuration, and the server knows nothing about the location of the STS.

The way I understand the flow:
1. Client wants to call Service
2. Service requires a token from an STS (but doesn't specify which STS)
3. Client is configured to know the location of an STS
4. Clients does an RST to the STS
5. STS does an RSTR to the Client
6. Client accesses Service with token
7. Service verifies token is from an STS it trusts


To me this puts too much burden on the client. The client has to know both the location of the Service and the location of an STS.


Is it possible via WSIT configuration to make the Service tell the Client the location of the STS it should get a token from? Something like:

1. Client wants to call Service
2. Service requires a token from an STS, and tells Client where it is
3. Clients does an RST to the specified STS
4. STS does an RSTR to the Client
5. Client accesses Service with token
6. Service verifies token is from the STS it trusts


Thanks!
Silas
[Message sent by forum member 'smitty22s' (silas.smith@...)]

http://forums.java.net/jive/thread.jspa?messageID=370236

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

>
>
> Is it possible via WSIT configuration to make the
> Service tell the Client the location of the STS it
> should get a token from?

Yes, of course. If you use Netbeans to configure Metro based
service to b esecure with issued tokens, then the STS address/Metadata address
is set as specified in step 7 of:
https://metro.dev.java.net/guide/Example_Applications.html#ahiey

In this case step 8 of client configuration:
https://metro.dev.java.net/guide/Example_Applications.html#gfrls
is unnecessary.

In other words:

you may have  an Issuer element in the IssuedToken policy assertion in the service wsdl to specify the STS information:

 <sp:IssuedToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                            <Issuer xmlns="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                                <Address xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/jaxws-s5-sts/sts</Address>
                                <Metadata xmlns="http://www.w3.org/2005/08/addressing">
                                                            <Metadata xmlns="http://schemas.xmlsoap.org/ws/2004/09/mex" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                                                                <wsx:MetadataSection>
                                                                    <wsx:MetadataReference>
                                                                        <Address xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/jaxws-s5-sts/sts</Address>
                                                                    </wsx:MetadataReference>
                                                                </wsx:MetadataSection>
                                                            </Metadata>
                                                         </Metadata>
                            </Issuer>
                            <sp:RequestSecurityTokenTemplate>
                                ...
                            </sp:RequestSecurityTokenTemplate>
 <wsp:Policy>
                                <sp:RequireDerivedKeys/>
                                <sp:RequireInternalReference/>
                            </wsp:Policy>
                        </sp:IssuedToken>

>Something like:
>
> 1. Client wants to call Service
> 2. Service requires a token from an STS, and tells
> Client where it is
> 3. Clients does an RST to the specified STS
> 4. STS does an RSTR to the Client
> 5. Client accesses Service with token
> 6. Service verifies token is from the STS it trusts
>
>
> Thanks!
> Silas

[Message sent by forum member 'jdg6688' (jiandong.guo@...)]

http://forums.java.net/jive/thread.jspa?messageID=370239

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

Jiandong, thanks for getting back so quickly.

I removed the PreconfiguredSTS declaration from my wsit-client config, and added the Issuer block to my service config, and that works. But I still have the old wsit-client STS port binding policy in the client app, which also contains the login callback handler.

Is it possible to declare a "default STS port binding policy" that would be used to bind to whatever STS was specified by the service? The binding policy would contain the callback handler and the truststore declaration.

Thanks,
Silas
[Message sent by forum member 'smitty22s' (silas.smith@...)]

http://forums.java.net/jive/thread.jspa?messageID=370242

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[metro-3]

>
> Is it possible to declare a "default STS port binding
> policy" that would be used to bind to whatever STS
> was specified by the service? The binding policy
> would contain the callback handler and the truststore
> declaration.
>
No. Not now. In any case, you need to specify
the cert to use for each STS, not a generic one.
However you may set the username/password programmatically so that
it can be used by any STS call.
[Message sent by forum member 'jdg6688' (jiandong.guo@...)]

http://forums.java.net/jive/thread.jspa?messageID=370381

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...