Everything is customizable but SessionFeature (Also it is derived from IPlugin :) ) is mandatory.
I want to use MySessionFeature:IPlugin but everywhere in Controller,Attribute ... it is used as strong-typed.
Is it by-design or something else?
SessionFeature contains useful overloads and sets the ss-id,ss-pid and ss-opts cookies on the response that are required for everything in ServiceStack that relies on the Session to work like the IAuthSession/CustomUserSession and Authentication.
You can register the Session plugin without Authentication, but when you register the Authentication plugin it will automatically register the Session Plugin if you haven't already.
Related
I am planning to implement SSO w/OIDC between several identical Websphere Liberty profile (wlp) instances with the standard LtpaToken2 cookie, but I don't see it being generated under that name. Instead, I see a random WAS_* cookie.
Even when I set it manually in 1 single wlp's server.xml like:
<webAppSecurity ssoCookieName="LtpaToken2" />
I see that wlp intentionally ignores it, as seen in the logs:
[AUDIT] CWWKS9112A: The web application security settings have changed.The following properties were modified: ssoCookieName=WAS_p1887216770
so it doesn't seem to be an app-related issue, or even oidc-related issue.
Why is wlp behaving like this? All the existing documentation doesn't mention any restriction/reservation of the LtpaToken2 name, in fact it should be the default.
Although I can set it to any other custom name, I am interested in understanding this impediment in using the default LtpaToken2 name, and the reason why it doesn't align with the documentation.
Any explanation is deeply appreciated
Enabling either the openidConnectClient-1.0 or openidConnectServer-1.0 will cause the cookie name to be automatically generated with a server specific identifier for either one of those features. In some situations, this allows configuring multiple Relying Parties and Providers in the same host without collisions when processing their respective cookies.
For the openidConnectProvider, you have the option to use LtpaToken2 when setting the allowDefaultSsoCookieName attribute to "true" as documented in https://www.ibm.com/docs/en/was-liberty/nd?topic=configuration-openidconnectprovider. The openidConnectClient does not provide this option. We have an issue open to allow using the default cookie name for the OIDC client at https://github.com/OpenLiberty/open-liberty/issues/18803.
On the other hand, you might benefit from using jwtSso-1.0 to do SSO between identical servers after the initial authentication with the OIDC Provider. For example, please see the documentation for the allowCustomCacheKey attribute in https://www.ibm.com/docs/en/was-liberty/nd?topic=configuration-openidconnectclient.
Another alternative is to specify a value other than LtpaToken2 for the ssoCookieName attribute. This will override the auto generation of the cookie name when those features are enabled.
Regards,
Teddy
I need to add the new claim ("end_session_endpoint") in OidcProviderConfiguration because UI needs to get that claim, besides the default ones, in /.well-known/openid-configuration response.
Is that possible?
Note: I'm using Spring Authorization Server version 0.2.2
It's not yet possible (as of this writing), but very close! Take a look at Ability to modify OIDC provider configuration #616 to follow progress on this issue.
Can anyone save some of my hair? :)
I'm trying to create an asp.net WEB API interface for an older CSLA (1.x/2.x era) project. I am testing by hard coding the login on every request in various ways (once in the startup code, as an authorization request filter, inside the individual route request etc etc). All the ways I tried work exactly once perfectly and then I get the infamous:
'Default principal object cannot be set twice.'
exception in BusinessPrincipal.vb (yeah I know it's very old, but it's released software, I can't upgrade CSLA)
I know that there is an issue where you need to set HttpContext.Current.User = Thread.CurrentPrincipal; due to some internal workings of the web API and I do that already, that has not resolved the issue.
I'd like to know if anyone has implemented a web api front end and how they handled this issue or any pointers as to what could be the solution.
Worst case scenario if I could at least just login once and keep that same principal without losing it I could implement a second layer of security, that woudld be acceptable, barring anything else is there some way to just login once and not lose that principal?
That BusinessPrincipal class would be in your code base, not in CSLA itself. The Csla.Security namespace does include a BusinessPrincipalBase that is probably the base class for your BusinessPrincipal.
Classes in that namespace are here in GitHub
It is true that you can only call AppDomain.SetPrincipalPolicy one time, but you should be able to set the Thread.CurrentPrincipal and HttpContext.Current.User multiple times.
I am currently implementing SSO with DotNetOpenAuth. However, when working locally, I need to send requests via a proxy. I am happy to do this programatically or via config setting but I am struggling to find where to add it to the TwitterConsumer class supplied in the application block.
Any help much appreciated
So the easiest way is probably to set the proxy in your .config file or programmatically using WebRequest.DefaultWebProxy.
Alternatively, just set the proxy properties on the HttpWebRequest objects like any other .NET request. For those request objects you don't see because DotNetOpenAuth creates and issues them automatically, you can implement IDirectWebRequestHandler and pass that into DNOA so you get to intercept each outgoing HttpWebRequest, but that is considerably harder and probably not necessary considering your other options.
Is there a way to change the scope/permission when using Microsoft.Web.WebPages.OAuth? The most logical place is when registering the client with OAuthWebSecurity.RegisterClient. I thought that the adding scope to the extraData parameter would possibly work, but I didn't have success with that.
Microsoft.Web.WebPages.OAuth does not expose the scope when authorizing with a client. I ended up adding custom DotNetOpenAuth clients to include my necessary scope.
The extradata is something you can pass about the provider and use it in tehe UI layer. For eg. extra data could be the icon to display when listing the provider to use for login.
Following post shows how you can write your own provider and plug it into your site
http://blogs.msdn.com/b/webdev/archive/2012/08/23/plugging-custom-oauth-openid-providers.aspx