I am looking to have multiple entity IDs point to the same IDP. Looks like I can do this with an entity alias but adding that to the extended metadata didn't make any changes.
For the alias approach, you may want to add more details on how you have configured your extended metadata and the behavior you are experiencing.
Also, assuming you have SP initiated flow, there is another way to have multiple SP(identical) point to the same IDP while holding identical SP metadata xml. This would involve you to provide configure a parameter assertionConsumerIndex in your bean configuration for MetadataGeneratorFilter. See below:
<bean id="metadataGeneratorFilter" class="org.springframework.security.saml.metadata.MetadataGeneratorFilter">
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.MetadataGenerator">
<property name="entityId" value="<YOUR-ENTITY-ID-SAME-ON-ALL-SP>"/>
<property name="assertionConsumerIndex" value="<INT-VALUE-DIFF-ON-EACH-SP>" /> <!-- value e.g. 1, 2, 3 etc -->
Then on the IDP, these indexes will correspond to particular endpoint urls within the same IDP instance. Not sure if this fits your scenario but wanted to make you aware of another option. You should be able to find more information by searching for "assertionConsumerIndex" in the documentation
Related
Today I learned that on server farms, I must not use validationKey="AutoGenerate", but specify a 'fixed' string value for validationKey, for consistency across request handling by the farm servers. The example given was:
<machineKey
validationKey="21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4374267A75D7
AD972A119482D15A4127461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"
decryptionKey="ABAA84D7EC4BB56D75D217CECFFB9628809BDB8BF91CFCD64568A145BE59719F"
validation="SHA1"
decryption="AES"
/>
I was under the impression that the generation of a new key for every request and every user enhanced security quite a bit, but if the key is constant, it be retrieved from the hidden field on a form and used in a forged request.
Or must I cease using hidden fields for this key when on a server farm and use a header or cookie instead?
I say the anti-forgery key is stored in the form because this Razor markup:
#Html.AntiForgeryToken()
renders this HTML:
<input name="__RequestVerificationToken" type="hidden" value="bH6_-oZcRMuC9tA13RrOzmr0N3sWrzgkjKOhg2igHs5K2-G0HbJbF3KaK-QMrUDcQTXFbHJ-HFMNn9AjvF-TkAuBFo5f8Afi8q0OHXBzOTI1">
Unless we are talking about different keys here, but how would that work?
No, it's not a security risk.
The autogenerated key is not sent in a hidden field in the form, it's stored in the Local Security Authority (LSA) on the server (ref). If the key was sent in the form then there would be no need to have the same key on multiple servers. There would also not be any need to retrieve a key to forge a request, you could just send whatever key you wanted in a request.
With autogeneration the server doesn't generate a new key for each request, it generates a key for the server (or for the application if the IsolateApps option is used). It's only the message authentication code (MAC) that is generated for each request.
I was making some changes to security.xml regarding the access like:
<intercept-url pattern="/app/admin/projectform*" access="ROLE_ADMIN,ROLE_ENGAGEMENT_MANAGER"/>
But I am confused how to differentiate between the following two URLs:
/userform?create=Engagement&method=add&from=list
/userform?create=manager&method=add&from=list
They need to be assigned to different roles.
I tried to do something very similar but couldn't. On inspecting the source code I realised spring-security doesn't consider request parameters when applying coarse grain/url authorization.
I ended up creating two separate urls.
I have the same issue. I debugged and found out that Spring failed to parse separated roles with comma actually it throws ParseException at doParseExpession. you can find the exact line [here][1]
It says it missing some data if there is acomma`. I haven't figure why. But, it seems that #Oliver advice is a good one for now. i.e break the rules for two/more lines
Edit
Solution:
seems that in version 4 filter-security-metadata-source expect to get request-matcher AND use-expressions i.e try:
<filter-security-metadata-source request-matcher="ant" use-expressions="false">
<intercept-url pattern="/app/admin/projectform*" access="ROLE_ADMIN,ROLE_ENGAGEMENT_MANAGER"/>
</filter-security-metadata-source>
I'm new to Spring security. Now I'm reading its documentation. I have a question regarding to its filter chain url patterns:
As explained in the document:
it's possible to use multiple http elements to define different security configurations for different URL patterns. Each element creates a filter chain within the internal FilterChainProxy and the URL pattern that should be mapped to it. The elements will be added in the order they are declared, so the most specific patterns must again be declared first.
it also gives an example:
<!-- Stateless RESTful service using Basic authentication -->
<http pattern="/restful/**" create-session="stateless">
<intercept-url pattern='/**' access='ROLE_REMOTE' />
<http-basic />
</http>
what I don't understand is:
A URL pattern "/restful/**" is already configured for the http tag, it means all request matching this pattern will be handled by the filter chain inside this http tag. However why it gives a "match all" pattern: "/**" to the intercept-url tag?
Isn't it duplicated?
Also, if really want to give another pattern, isn't "/restful/**" better? Cause "/**" will match URLs that will not match "/restful/**" and thus not be handled by this filter chain.
Without the <intercept-url> tag within <http>, this declaration basically says that anyone can access any resource under the /restful/** path. The <intercept-url> here restricts access to users who have been assigned the ROLE_REMOTE role, which is quite different.
<intercept-url> patterns are relative to the enclosing <http> element pattern, so nothing outside the /restful/** path will be intercepted by this declaration.
The typical pattern is that you will have one <http> element with several <intercept-url> elements within targeting different URL patterns. Additional <http> elements can be useful when you want authentication and access control to behave differently, for example session management or authentication failure handlers for REST API endpoints.
I use mule-standalone-3.3.0 CE. I create pattern web service proxy, and my config:
<pattern:web-service-proxy name="WebService"
wsdlLocation="http://www.tset.com/WebService/Tse.asmx?WSDL"
inboundAddress="http://localhost:8084/test"
outboundAddress="http://www.tset.com/view" />
I want to put username and password on my new wsdl (http://localhost:8084/test?wsdl).
What is the best way for do that?
I know some way such as: "using spring security" but I don't know this way is good or no.
and I have a problem about spring security:
I don't know how to set SoapUi? I don't know how to send authentication headers within my soapUI?
The web service pattern can be defined in an extended way that allows the definition of child elements. By using it you will be allowed to define the security filter leveraging spring security
Your pattern configuration should look like the following:
<pattern:web-service-proxy name="WebService"
wsdlLocation="http://www.tset.com/WebService/Tse.asmx?WSDL">
<http:inbound-endpoint address="http://localhost:8084/test" >
<mule-ss:http-security-filter realm="mule-realm"/>
</http:inbound-endpoint>
<http:outbound-endpoint address="http://www.tset.com/view" />
</pattern:web-service-proxy>
I am trying to fetch data from a service that i donot know much about.
So i got its url like
http://ABC.com/ABC.svc
so i thouhgt to get metadata as
http://ABC.com/ABC.svc/$metadata
it gives me:
<EntityType Name="E1">
- <Key>
<PropertyRef Name="E1k1" />
</Key>
< Property Name="E2" Type="Edm.String" Nullable="true"
m:FC_TargetPath="SyndicationTitle" ..>
<ComplexType Name="OptionV1">
<Property Name="Value" Type="Edm.Int32" Nullable="true" />
... and a lot more.
How do i find out what should come next to ABC.svc/???
I want to write queries to access data. Can smebody point me to what should be my next steps?
and any learning resource on this query generation from metadata would be hlpful.
Thanks
There are two ways:
1) Using the service document. Navigate to the ABC.svc, that should return a service document, that is an ATOM Service payload which contains the names of the entity sets available from the service. For a sample of such you can go to http://services.odata.org/OData/OData.svc/. This should return a document with three collections (Entity sets). The href attribute is a relative URI to the entity set (relative to the xml:base which is usually the base of the service). So if for example your service has an entity set E1Set, then typically the address of it would be ABC.svc/E1Set.
2) Using the $metadata document and assuming the usual addressing scheme (note that this usually applies to the service but it doesn't have to). The $metadata document will define entity sets. Each of these is usually exposed by the service and typically follows the addressing scheme of ABC.svc/EntitySetName.
Once you navigate to the entity set, you should get back an ATOM feed with the entities in that set. The $metadata will help you recognize the shapes of the entities and the relationships.
Some services also have service operations or actions and so on. These are not exposed in the service document #1. Instead they are only visible in the $metadata as FunctionImport elements. They usually follow the addressing scheme of ABC.svc/FunctionImportName. But note that you might need to know something more about the service operation to be able to invoke it (what HTTP verb to use, what are the parameters, what it will do, and so on).
LinqPad provides a very simple means for getting started with OData services (assuming some familiarity with LINQ). If you will primarily be primarily consuming this application from .NET, I'd recommend starting with this application. You point it to the $metadata endpoint and it generates proxy classes which allow you to work with the OData service much like you would in a plain-old-.NET-app. On the Results Log tab, it will output the URL used to query the OData service, which you can then pick up and tweak in Fiddler. (For more about how to use OData + Fiddler, see this blog post.)
If you'll primarily be using the OData service from JavaScript, you might want to start by understanding the URI conventions better or by playing around with data.js.