I have a usecase where the application logic needs to add a (dynamically generated) extension to the authnrequest. Perhaps the right way to do this is to make a way for the application to provide a complete authnrequest to a SessionInitiator which the SP (optionally sign) and pass along to the IdP. I think it is safe to assume that the application can deal with discovery too in this case.
I guess I'm thinking I handle it with a base64-encoded parameter, likely via POST but I can just pull it from either as long as it's consistently encoded.
Scott Cantor June 14, 2016 at 6:46 PM
In looking at this in conjunction with SSPCPP-424, I'm finding myself slightly concerned about the security implications of this. I don't think we should preclude it, but building in some options to limit whether the code will honor outside influence seems prudent.
I'm thinking that should apply to both the existing parameters to the SessionInitiator URL and anything we do here.
Scott Cantor April 16, 2015 at 9:17 PM
That's probably a reasonably simple way to go. I'd like to be able to take on more of the work, but that's a baseline to start with.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
I have a usecase where the application logic needs to add a (dynamically generated) extension to the authnrequest. Perhaps the right way to do this is to make a way for the application to provide a complete authnrequest to a SessionInitiator which the SP (optionally sign) and pass along to the IdP. I think it is safe to assume that the application can deal with discovery too in this case.