Creating referral policies in openam through ssoadm - authentication

In openam I created a subRealm named TestRealm .In order to create policies in TestRealm there should be a referral policy. Im trying to create a policies for TestRealm with the help of ssoadm command, but its throwing a error Cannot create policy. No referral exists to the organization. Im using the following policy.xml to create policies under the root realm.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Policies PUBLIC "-//OpenSSO Policy Administration DTD//EN" "jar://com/sun/identity/policy/policyAdmin.dtd">
<!-- New policy, same as the old policy -->
<Policies>
<Policy name="Test Policy" referralPolicy="false" active="true" >
<Rule name="Test Allow GET with parameters">
<ServiceName name="iPlanetAMWebAgentService" />
<ResourceName name="http://www.test.com/demo/*?*" />
<AttributeValuePair>
<Attribute name="GET" />
<Value>allow</Value>
</AttributeValuePair>
</Rule>
<Rule name="Vidz Ref Allow GET and POST">
<ServiceName name="iPlanetAMWebAgentService" />
<ResourceName name="http://www.test.com/demo/*" />
<AttributeValuePair>
<Attribute name="POST" />
<Value>allow</Value>
</AttributeValuePair>
<AttributeValuePair>
<Attribute name="GET" />
<Value>allow</Value>
</AttributeValuePair>
</Rule>
<Subjects name="Subjects" description="Everybody authenticated">
<Subject name="All Authenticated Users" type="AuthenticatedUsers" includeType="inclusive">
</Subject>
</Subjects>
</Policy>
</Policies>
How to modify the above one to create a referral policy??

The easiest way would be to simply create an example referral in the top level realm, and then just export it via ssoadm for subsequent imports. Also you should use very generic rules in referrals, like http://www.test.demo.com/* and http://www.test.demo.com/*?*, having complex rules in referrals will only slow down policy evaluation without much of a point (the referred policies will be used to make the allow/deny decision in the end anyways).

Related

How to integrate Azure B2C User migration technical profile in a custom Sign In profile?

I'm reading Azure Active Directory B2C: User migration and having a hard time trying to figure out how to integrate the Technical Profile described there into my custom Sign In policy:
<ClaimsProvider>
<DisplayName>REST APIs</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="LocalAccountSignIn">
<DisplayName>Local account just in time migration</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">http://{your-app}.azurewebsites.net/api/PrePasswordReset/LoalAccountSignIn</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
<TechnicalProfile Id="LocalAccountPasswordReset">
<DisplayName>Local account just in time migration</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ServiceUrl">http://{your-app}.azurewebsites.net/api/PrePasswordReset/PasswordUpdated</Item>
<Item Key="AuthenticationType">None</Item>
<Item Key="SendClaimsIn">Body</Item>
</Metadata>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
I already have a custom SignIn policy called SignInOnlyKMSI. However I'm not sure how to hook that Technical Profile into my policy.
I opened an issue # the repo:
https://github.com/yoelhor/Azure-AD-B2C-UserMigration/issues/2
however I don't think the repo maintainer is active.
They forgot to add the policy files to the repo and the explanation is not that good. It's missing some pieces.
Please use the latest version of the user migration. I moved to the Azure AD B2C community repo.
Yoel
After fiddling with it I got it to work as expected...
In this part in the documentation:
After you define the technical profile for your RESTful API, tell your
Azure AD B2C policy to call the technical profile. The XML snippet
overrides SelfAsserted-LocalAccountSignin-Email, which is defined in
the base policy. The XML snippet also adds ValidationTechnicalProfile,
with ReferenceId pointing to your technical profile
LocalAccountUserMigration.
They tell you WHAT needs to be done but don't actually tell you HOW...
I figured it out. You need to add a new Technical Profile like the following one just below the other two in the same file TrustFrameworkExtensions.xml:
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
<!-- <OutputClaims>
<OutputClaim ClaimTypeReferenceId="loyaltyNumber" PartnerClaimType="loyaltyNumber" />
</OutputClaims> -->
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="LocalAccountUserMigration" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
Note the <ValidationTechnicalProfile ReferenceId="LocalAccountUserMigration" />. Just rename the 1st technical profile from LocalAccountSignIn to LocalAccountUserMigration.

How to ignore Liferay user removed from LDAP errors?

I have a Liferay 6.1 instance that is connected to LDAP. New users get imported nicely, but when I remove a user from the LDAP directory, Liferay starts throwing exceptions when it tries to sync users from LDAP.
These seem to be safe to ignore, but they produce several megabytes of log and it makes log parsing highly annoying. Also I think it might affect performance. If a deleted user logs in, they see nothing.
16:13:54,422 ERROR [liferay/scheduler_dispatch-790][PortalLDAPImporterImpl:995] LDAP user not found with fullUserDN cn=foobar,ou=people,o=foo,dc=bar,dc=baz
javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=foobar,ou=people,o=foo,dc=bar,dc=baz'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3057)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2978)
... etc
How could I convince Liferay that this is really OK? Or is there something else I should do?
Until missing users in LDAP are supported by Liferay you can turn off the logging for this particular message. Just create the file ROOT.war/WEB-INF/classes/META-INF/portal-log4j-ext.xml with the following content:
<?xml version="1.0">
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
<!-- Copy all appenders from
ROOT.war/WEB-INF/lib/portal-impl.jar/META-INF/portal-log4j.xml
and add the following filter: -->
<appender ...>
...
<filter class="org.apache.log4j.filter.StringMatchFilter">
<param name="StringToMatch" value="LDAP user not found with fullUserDN" />
<param name="AcceptOnMatch" value="false" />
</filter>
</appender>
<!-- Keep the root definition from portal-log4j.xml
to trigger the parsing of the appenders: -->
<root>
<priority value="INFO" />
<appender-ref ref="CONSOLE" />
<appender-ref ref="FILE" />
</root>
</log4j:configuration>
You can find more about logging in the Liferay Wiki.

Infinispan Initial State Transfer Hangs and times out

I'm trying to cluster a pair of servers with a shared Infinispan cache (Replicated Asynchronously). One always starts successfully, and registers itself properly with the JDBC database. When the other starts, it registers properly with the database, and I see a bunch of chatter between them, then, while waiting on a response from the second server, I get
`org.infinispan.commons.CacheException: Initial statue transfer timed out`
I think it's just an issue of configuration, but I'm not sure how to debug my configuration issues. I've spent several days configuring and re-configuring my Infinispan XML, and my JGroups.xml:
Infinispan:
<?xml version="1.0" encoding="UTF-8"?>
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:infinispan:config:6.0"
xsi:schemaLocation="urn:infinispan:config:6.0 http://www.infinispan.org/schemas/infinispan-config-6.0.xsd
urn:infinispan:config:remote:6.0 http://www.infinispan.org/schemas/infinispan-cachestore-remote-config-6.0.xsd"
xmlns:remote="urn:infinispan:config:remote:6.0"
>
<!-- *************************** -->
<!-- System-wide global settings -->
<!-- *************************** -->
<global>
<shutdown hookBehavior="DEFAULT"/>
<transport clusterName="DSLObjectCache">
<properties>
<property name="configurationFile" value="jgroups.xml"/>
</properties>
</transport>
<globalJmxStatistics enabled="false" cacheManagerName="Complex.com"/>
</global>
<namedCache name="ObjectCache">
<transaction transactionMode="TRANSACTIONAL" />
<locking
useLockStriping="false"
/>
<invocationBatching enabled="true"/>
<clustering mode="replication">
<async asyncMarshalling="true" useReplQueue="true" replQueueInterval="100" replQueueMaxElements="100"/>
<stateTransfer fetchInMemoryState="true" />
</clustering>
<eviction strategy="LIRS" maxEntries="500000"/>
<expiration lifespan="86400000" wakeUpInterval="1000" />
</namedCache>
<default>
<!-- Configure a synchronous replication cache -->
<locking
useLockStriping="false"
/>
<clustering mode="replication">
<async asyncMarshalling="true" useReplQueue="true" replQueueInterval="100" replQueueMaxElements="100"/>
<stateTransfer fetchInMemoryState="true" />
</clustering>
<eviction strategy="LIRS" maxEntries="500000"/>
<expiration lifespan="86400000" wakeUpInterval="1000" />
<persistence>
<cluster remoteCallTimeout="60000" />
</persistence>
</default>
</infinispan>
Jboss.xml:
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.0.xsd">
<!-- Default the external_addr to #DEADBEEF so we can see errors coming through
on the backend -->
<TCP
external_addr="${injected.external.address:222.173.190.239}"
receive_on_all_interfaces="true"
bind_addr="0.0.0.0"
bind_port="${injected.bind.port:12345}"
conn_expire_time="0"
reaper_interval="0"
sock_conn_timeout="20000"
tcp_nodelay="true"
/>
<JDBC_PING
datasource_jndi_name="java:jboss/datasources/dsl/control"
/>
<MERGE2 max_interval="30000" min_interval="10000"/>
<FD_SOCK
external_addr="${injected.external.address:222.173.190.239}"
bind_addr="0.0.0.0"
/>
<FD timeout="10000" max_tries="5"/>
<VERIFY_SUSPECT timeout="1500"
bind_addr="0.0.0.0"
/>
<pbcast.NAKACK use_mcast_xmit="false"
retransmit_timeouts="300,600,1200,2400,4800"
discard_delivered_msgs="true"/>
<UNICAST3 ack_batches_immediately="true"
/>
<RSVP ack_on_delivery="true"
throw_exception_on_timeout="true"
timeout="1000"
/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="5000"
view_bundling="true" view_ack_collection_timeout="5000"/>
<FRAG2 frag_size="60000"/>
<pbcast.STATE_SOCK
bind_port="54321"
external_addr="${injected.external.address:222.173.190.239}"
bind_addr="0.0.0.0"
/>
<pbcast.FLUSH timeout="1000"/>
</config>
I've tried, frankly, every configuration option I can think of, and I'm not sure why the replication keeps timing out. All communication between these servers is wide open. Sorry to just dump so much XML, but I'm not even sure how to collect more information.
Continued exploration indicated that Infinispan was pushing logs to the server.log, but - due to my configuration, this was not duplicated on the console. Further inspection revealed that I left a single element in my cache objects unserializable - making it impossible for it to be written to the wire and transferred. The logs are very specific, making this actually a very easy problem to track down once I realized where the logs were being written.
If you come here from the future, my advice is to just tail every single log you can on the working server, and see what comes up.

Application Initialization Module for IIS 7.5 issue

As a part of Proof of Concept utilizing the Application Initialization Module for IIS 7.5 to increase the speed of web apps initialization, I have created a simple web application hosted on IIS 7.5 (Windows Server 2008 R2) with SSL enabled. Please see global and local settings below.
If I understand correctly the way the Application Initialization Module works, I am expecting IIS to issue a request to appinit.aspx (https://localhost/alwaysrunning/appinit.aspx) to initialize the web application. This is however never happening.
Any ideas?
What is the purpose of the attribute initializationPage?
Any help with this would be greatly appreciated.
EDIT: When I disable SSL the Application Initialization Module issues a request to appinit.aspx as expected. I need to get this to work with SSL enabled though.
Zen
Global settings in the applicationHost.config file:
<add name="appinit" autoStart="true" startMode="AlwaysRunning">
<recycling logEventOnRecycle="Time, Requests, Schedule, Memory, IsapiUnhealthy, OnDemand, ConfigChange, PrivateMemory">
<periodicRestart requests="0" time="00:05:00">
<schedule>
<clear />
</schedule>
</periodicRestart>
</recycling>
<processModel identityType="NetworkService" idleTimeout="00:00:00" />
</add>
<application path="/alwaysrunning" preloadEnabled="true" applicationPool="appinit">
<virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\alwaysrunnig" />
</application>
Local settings in application's web.config file:
<applicationInitialization remapManagedRequestsTo="splashscreen.htm" skipManagedModules="true" >
<add initializationPage="/appinit.aspx" />
</applicationInitialization>
(I know, stale question, but it's unanswered & came up in my own Google search on the subject.)
Refer to the following article from Microsoft Support:
Application Initialization module fails when web site requires SSL (KB2843964). Quote:
Cause
This behavior is by design.
Resolution
To workaround this limitation, you may consider enabling HTTP (uncheck
the "Require SSL" setting in IIS Manager/SSL Settings) and use a URL
Rewrite rule to redirect HTTP requests to HTTPS with the exception of
the request coming from the warmup module :
<rewrite>
<rules>
<rule name="No redirect on warmup request (request from localhost with warmup user agent)" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="localhost" />
<add input="{HTTP_USER_AGENT}" pattern="Initialization" />
</conditions>
<action type="Rewrite" url="{URL}" />
</rule>
<rule name="HTTP to HTTPS redirect for all requests" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" />
</rule>
</rules>
</rewrite>
Gotta love "This behavior is by design." Sigh. Sadly, the top search results I found about this Application Initialization feature fail to mention this limitation — unless one interprets "HTTP request" as strictly meaning non-secure requests.

How to write XACML Policy using Custom Attributes

I'm trying to write an XACML policy that will utilize a custom attribute. I'm thinking of something like:
<?xml version="1.0" encoding="UTF-8"?>
<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" PolicyId="deny-demo100"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">
<Description> </Description>
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<Rule Effect="Deny" RuleId="rule-deny-demo100">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<AnyResource/>
</Resource>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">customAttribute</AttributeValue>
<ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action- id" MustBePresent="false" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>
</Action>
</Actions>
</Target>
</Rule>
<Rule RuleId="deny-demo100-catch-all" Effect="Permit" />
</Policy>
(We're using Fedora's XACML implementation).
I'm sure I'm missing something really simple and fundamental here, but cannot figure out what. Could someone point me in the right direction please?
What do you mean by custom attribute? What is it you want to express in 'plain old English'?
In XACML you can use any attribute you like such as role, citizenship, clearance, resource classification, time of day... Of course the availability of the attribute depends on the type of app you are protecting. How are you using the Fedora implementation? Is it for access control within Fedora Linux OS?
If you want to compare an attribute to a value e.g. citizenship == Canadian, then use a <Target/>. If you want to compare 2 attributes together e.g. clearance > classification, then use a <Condition>.
I am not sure what you are actually looking for, but I guess you need to do some attribute-based access control.
In XACML there is a component called PIP (Policy Information Point), where you can retrieve attributes from external sources and check authorization.
This may help you: Understanding PIP (Policy Information Point).
If you need to create XACML policies in a easier way, you can follow this: XACML Policy Editor in WSO2 Identity Server.
I have to admit I'm kinda new to XACML and Fedora's implementation of it, but my understanding is you should be able to query any value that appears when checking the user object. The URL on a default Fedora Commons install should be "localhost:8080/fedora/user" and yields the following object on my server after logging in a previously created LDAP user called "Joe User":
<user id="Joe User">
<attribute name="uid">
<value>userj</value>
</attribute>
<attribute name="mail">
<value>UserJ#ldap.test.user.uconn.edu</value>
</attribute>
<attribute name="sn">
<value>User</value>
</attribute>
<attribute name="ou">
<value>DPT</value>
</attribute>
<attribute name="cn">
<value>Joe User</value>
</attribute>
<attribute name="description">
<value>sample user</value>
</attribute>
<attribute name="role"/>
<attribute name="fedoraRole"/>
<attribute name="objectClass">
<value>organizationalPerson</value>
<value>person</value>
<value>inetOrgPerson</value>
<value>top</value>
</attribute>
<attribute name="displayName">
<value>Joe User (LDAP)</value>
</attribute>
</user>
Once a value has been injected into the user object via some JAAS authentication module (as in the above case using the LDAP module) or even an environment variable you should be able to query it. In the example policy below I've set Fedora to grant fedoraAdmin like access to API-M calls if a user has an OU set to "DPT":
<?xml version="1.0" encoding="UTF-8"?>
<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
PolicyId="permit-apim-to-ldap-ou"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
>
<!-- test policy to approve API-M operations if a specific LDAP OU exists -->
<!-- make sure access to API-M in premitted from the current client IP address first (check "deny-apim-if-not-in-list.xml" or "deny-apim-if-not-localhost.xml" ) -->
<Description>note that other policies may provide exceptions to this broad policy. This policy assumes api-m users have to be authenticated</Description>
<Target>
<Subjects>
<Subject>
<!-- specific OU - need to get this working with a range of values -->
<SubjectMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">DPT</AttributeValue>
<SubjectAttributeDesignator AttributeId="ou" MustBePresent="false" DataType="http://www.w3.org/2001/XMLSchema#string"/>
</SubjectMatch>
</Subject>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<Rule RuleId="1" Effect="Permit"/>
</Policy>
Custom attributes can even be added the Fedora XML User file (not the Tomcat user file) rather than using LDAP. Likely there is a better way to do this, but as I stated before I'm rather new to XACML and don't fully understand it. This rule works on my localhost test server based on the other rules also in place. Your mileage may vary.
Also, as stated in the sample policy file, make sure that the client you are testing from can both be permitted and then later denied API-M access before you put a rule like this in place as debugging XACML policies in Fedora seems to be extremely difficult with little data being written to the log file even in Debug mode (you will see an operation passed or failed but never the name of the rule that caused the pass/fail result to happen).