I am totally new in SAML SSO connection so, can anyone provide me the sample codes and libraries(jar etc) to establish the connection, The following parameters are provided by the third party application to which i need to connect via SAML2,
SAML Assertion Consumer Hub
Audience Entity ID
IssuerID
URL (for POSTing)
UserID/Username
A level 2 (also called Class 2) certificate
Related
I'm building an API gateway using Spring Cloud Gateway and I'd like to secure it.
In our current architecture the API gateway will be hidden behind a portal which authenticates using a client certificate (issued for a system user) and sends the name of the real user calling the service in an HTTP header.
I'm looking for a way to configure Spring Security to both verify the certificate (so that nobody else can call the GW) but at the same time construct the principal from the provided header (after the cert check succeeds).
If I use the standard x509 from Spring Security (with provided subjectPrincipalRegex) the user service receives just the matching part as the user ID so I can construct the Principal from the username in the cert (which is still the same).
I.e. I'm looking for something like this
No client cert or invalid client cert => anonymous user (still can have access to some routes)
Valid certificate => obtain UserDetails based on the HTTP header (which can still result in user not found in the DB, i.e. anonymous access).
Note: Since Spring Cloud Gateway is reactive I'm looking for solution applicable to Spring WebFlux Security but I believe that the concepts are the same as in "standard non-WebFlux" security
I am trying to integrate(SSO) multiple service providers using spring security and wso2 identity server 5.1.0 I have integrated spring security SAML sample with Wso2 IS as according to the blog for only one service provider and its running perfectly fine, but I am not able to do SSO for multiple service providers. I have checked everything but no luck.
Please find below what I think it should be but I am not sure how to achieve this.
WSO2 IS : created a service provider with unique SAML issuer id(ex. spring-security),which will be used from different service providers for SSO.
SP1 : Service provider should send Authn request having issue id(spring-security) and a assertion consumer url(ex. localhost:8080/...).
SP2 : Service provider should send Authn request having issue id(spring-security) and a assertion consumer url(ex. localhost:8181/...).
Issuer in Authn Request :
http://localhost:8080/spring-security-saml2-sample/saml/metadata
Even I am not sure how this issuer is being generated.
Please help.
You have to use different and unique entity ids for each service provider. And at Identity Server you need to create multiple service providers (2 in your case) accordingly in order to get SSO (and SLO) working.
So let's say you get the entity ids changed for two SPs as spring-security-1 and spring-security-2. You will need to create 2 service providers at IS as below.
SP1 -> issuer : spring-security-1 , ACS url : localhost:8080/...
SP2 -> issuer : spring-security-2 , ACS url : localhost:8081/...
I am trying to use the WebSphere Liberty Profile OIDC Client feature. I have the feature installed and configured, but I am confused about what URL I should be using to connect to it. In the WLP Knowledge Center, it shows an example like this:
https://server.example.com:443/oidc/endpoint/PROVIDER_NAME/authorize
But when my WLP server comes up, I see the following URL in the log:
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost I addWebApplication SRVE0250I: Web Module OpenID Connect Client Redirect Servlet has been bound to default_host.
com.ibm.ws.http.internal.VirtualHostImpl A CWWKT0016I: Web application available (default_host): http://ibm669-r9v0dvb:11080/oidcclient/
I don't know whether to use 'oidcclient' (probably) or 'oidc'. I also don't know what to put as the PROVIDER_NAME. I tried using the ID of my OIDCClient:
<openidConnectClient id="oidcRP"
clientId="${oauth.client.id}"
clientSecret="${oauth.client.secret}"
authorizationEndpointUrl="${oauth.authorize.endpoint}"
tokenEndpointUrl="${oauth.token.endpoint}"
httpsRequired="false"
redirectToRPHostAndPort="https://myhost.com:443">
I tried connecting with this, but it's not finding it:
http://ibm669-r9v0dvb:11080/oidcclient/endpoint/oidcRP/authorize?scope=openid&response_type=code&client_id=XXX&redirect_uri=https://myhost.com:443
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor W handleRequest SRVE0190E: File not found: /endpoint/oidcRP/authorize
Can anyone tell me what URL I should be using to connect to the client?
The Liberty openidConnectClient feature enables Liberty as a client to openid connect provider. The configuration parameters inside openidConnectClient are information about openidConnectProvider, for example, the openidConnect provider's authorization endpoint and token endpoint.
What is your openid connect provider? Liberty also can be configured as openid Connect provider. If you also want to use Liberty as openid connect provider, you can create another Liberty instance and enable openidConnectProvider feature.
I am working on a proof of concept using Azure Active Directory Access Control Fig. 4 at The fundamentals of Azure identity management is the model I am shooting for. Since I need manage my own identifies in a deep heritage SaaS solution, I am setting up my own OpenID provider. For that, I am using DotNotOpenAuth. In my very vanilla, "hello world" example, I built a simple MVC app and registered it in my Access Control Service Namespace as a Relying Party Application and also registered the OpenIdProviderMvc project as-is from DotNetOpenAuth.Samples as my OpenID Provider using ACS Management Service. Here is the view I registered,
var openIdAddress = new IdentityProviderAddress
{
Address = "...localhost...",
EndpointType = "SignIn"
};
svc.AddRelatedObject(openId, "IdentityProviderAddresses", openIdAddress);
svc.SaveChanges();
which is the OpenID Provider endpoint page expecting to receive OpenID authentication messages to allow users to log into other web sites. This works well, when I launch my relying party application, where I installed the appropriate Nuget packages for DotNetOpenAuth (core, relying party, and their dependencies), the OpenID Providers gets called from the configuration in ACS and log in is successful. However, on redirection to ACS sending to my namespace the OpenID response, (...accesscontrol.windows.net/v2/openid?...) I get the error response:
An error occurred while processing your request.
HTTP Error Code: 502
Message: ACS30000: There was an error processing a sign-in response sent to the OpenID endpoint.
Inner Message: ACS30001: Unable to verify the OpenID response signature.
Inner Message: ACS90005: External server error.
Trace ID: 41338728-fd6e-4299-9efb-ad8684976aae
Timestamp: 2015-08-10 19:18:28Z
I am trying to figure our what I need to do to help ACS be able to verify the OpenID response signature. The response looks good (formatted for legibility and so I don't exceed my link restriction for low reputation):
https://....accesscontrol.windows.net/v2/openid?
context=cH...2
openid.claimed_id=.../user/bob
openid.identity=.../user/bob
openid.sig=NU...Rs=
openid.signed=claimed_id,identity,assoc_handle,op_endpoint,return_to,response_nonce,ns.alias3,alias3.mode,alias3.type.alias1,alias3.value.alias1,alias3.type.alias2,alias3.value.alias2,ns.sreg,sreg.email,sreg.fullname
openid.assoc_handle=WWcF!...
openid.alias3.type.alias2=.../namePerson&openid.alias3.value.alias2=bob
openid.ns.sreg=...openid.net/extensions/sreg/1.1
openid.sreg.email=bob#dotnetopenauth.net
openid.sreg.fullname=bob
Is this something I should be able to handle in the Rule Groups? Is there something I am missing in the security between my OpenId provider and ACS, such as sending some information back relating to signing algorithm, thumbprint, or something?
Thank you
I use SignalR 1.0.1 as a chat core for ASP.NET MVC3 application. Using IIS 7.5
There are two methods in MVC controller which provides access to chat views:
1. First method is public, allowing anonymous users to chat - no authorization.
2. Access to second method is restricted with [Authorize] attribute, for domain users - chat agents.
There is no explicitly specified authorization in the Hub.
For this scenario I involved both Windows and Anonymous authentication on IIS.
I also implemented custom Role Provider, which operates only in memory - not persisting anything to database.
What happens is that using '[Authorize]' attribute in controller method leads to responsing 500 from Hub, both when call is coming from authorized view, and the anonymous one:
Request (send is Hub method for sending messages):
http://localhost:8101/signalr/send?transport=serverSentEvents&connectionToken=VIXEZzWQSn5SNlA8RUy4iaOPDFdvuPBjMvFBiG2FLfvfxF347XHwtapsEV5ndU4OEI0Xb64W2ZRXTqwBiL2CXg2_JlTaTJ2RnVOj4bjvx6tQaYhAqTaXs9k2853GYqzd0
Response:
The connection id is in the incorrect format.
Server stack trace:
at Microsoft.AspNet.SignalR.PersistentConnection.GetConnectionId(HostContext context, String connectionToken)
at Microsoft.AspNet.SignalR.PersistentConnection.ProcessRequest(HostContext context)
at Microsoft.AspNet.SignalR.Owin.CallHandler.Invoke(IDictionary2 environment)
at Microsoft.AspNet.SignalR.Owin.Handlers.HubDispatcherHandler.Invoke(IDictionary2 environment)
at Microsoft.Owin.Host.SystemWeb.OwinCallContext.Execute()
at Microsoft.Owin.Host.SystemWeb.OwinHttpHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object extraData)<br/><br/>
But notice, that connecting to Hub works fine, returns 200 OK:
http://localhost:8101/signalr/connect?transport=serverSentEvents&connectionToken=dYOwFxa1mkgdpzw-jitRpWq9oxRlrTet8U_dAzWjFQEdGNJfVXeG7Op0NZZwvznxeNdJCuPT75CKzQqI9HRPThV3uEDt-Z2qtIl9E02gF481&connectionData=%5B%7B%22name%22%3A%22chathub%22%7D%5D&tid=9
I found little similiar thread here on stackoverflow:
signalr The connection id is in the incorrect format
from which I understand, that when invoking my Send method, the Hub is processing request with Identity different than the one used to connect to Hub, OR Hub's GetConnectionId finds, that user is actually not authorized - but how it checks that assumption, when there is no authorization specified on the Hub itself?
Can someone put some light on this?
Thanks in advance :)
SignalR signs both your connection id and your Identity together in order to create a new connectionToken every time you start a new connection. This connectionToken is then sent to the SignalR client as part of the negotiate response.
Every time you make a request to SignalR, whether it be a connect, reconnect, or send request, SignalR verifies that your connectionToken matches both your client's connection id AND Identity.
The connectionToken is essentially a CSRF token used in order to prevent attackers running third-party websites from surreptitiously making SignalR requests on behalf of shared clients. Obviously this doesn't help if you've enabled SignalR's cross-domain support, but the connectionToken still works the same in this case.
Taylor's answer was correct. You should stop and then start your SignalR connection when your client's Identity changes. This will force a new negotiate request which will give your client a new connection id with a new connectionToken signed with your client's updated Identity.
P.S. The server-sent events connect request isn't failing because it was established before your client's Identity was changed. The connectionToken is only checked at the request is received, but server-sent events keeps the response open indefinitely.
That's all true what you said and it actually takes place in my issue.
But I also found the the root cause:
One of main assumptions during design was to allow both anonymous users to use the chat without need to sign-in and the back-end users (agents) to sign-in to restricted area of chat using their Windows credentials.
So on the IIS manager I enabled both Anonymous authentication (allowing anonymous users to use the chat) and the Windows authentication (allowing agents to access using their Windows credentials).
MVC application is configured to use Windows authentication - the [Authorize] attribute mentioned in question, but only to restrict access for agent's view of chat.
What actually happens with above configuration is:
1. When client (agent) requests restricted View (let's say it's /Chat/Agent) the [Authorize] attribute initializes authentication (Windows)
2. Client-side Javascript requests Negotiate, what generates connectionId and binds it with client's Windows Identity
3. Here is the tricky part: Because Hub not uses any authentication explicitly, calling send method does not result in any authentication request - IIS Anonymous authentication takes precedency before Windows authentication, and send request is sent with anonymous Identity - but in Hub actual connectionId is related to Identity passed in point 2.
This scenario leads to situation you described - connect is called with different Identity than send and Hub returns The connection id is in the incorrect format.